01 Designer V60 AP - Accueil - Librairie Eyrolles · l’ouvrage Introduction to Groupware, ... L’attribut Statut de la classe Tâche prend les valeurs En attente, En cours, Effectuée,

��

��

��

Designer_1 17/11/03, 10:593

Les bases du développement Notes/Domino

© Tsoft et Groupe Eyrolles, 2004, ISBN : 2-212-11396-X

© Tsoft/Eyrolles – Lotus Domino Designer 6 : Bases du développement 11-1

Module 11 : Mettre en œuvre un workflow

Objectifs Ce module a pour objectif d’apprendre à traduire les diagrammes UML en programmes écrits en langage de formules pour un workflow Lotus Domino. Les ateliers contiennent des conseils et des techniques non décrites dans le cours.

Savoir-faire – Utiliser le routeur pour faire circuler les documents – Utiliser les rôles et les champs Lecteurs et Auteurs pour contrôler la visibilité et la

modification des documents – Gérer les accès à l’intérieur d’un document par section d’accès contrôlé – Contrôler l’état d’un document dans le workflow – Utiliser des documents profils

Connaissance – La typologie de workflow et Domino.workflow

Progression La typologie de workflow Domino Workflow Application de suivi de tâches Le routeur de messagerie Envoyer une notification à un utilisateur Envoyer un document

Atelier 11-1

Utiliser les rôles

Atelier 11-2

Modifier un document sous condition

Déterminer la visibilité d’un document Atelier 11-3

Créer une section d’accès contrôlé Contrôler l’état d’un document

Atelier 11-4, 11-5

Contrôler l’accès à une vue

Contrôler le masque utilisé dans une vue

Atelier 11-6, 11-7

Archivage de documents

Atelier 11-8

• Archivage • Champs Auteurs • Champs Lecteurs • Section d’accès

contrôlé • Sous-masque • Formule de masque • Notification • Routeur de messagerie

Chapitre 11 : Mettre en œuvre un workflow


La typologie de workflow Typologie de workflow

Workflow administratif

Formulaires : demandes de congés, d’achats de fournitures...

Workflow ad hoc

Orienté projet, procédures souples

Conçu sous forme de bases partagées de suivi

Workflow de production

Processus complexes faisant l’objet de procédures formelles

Impliquent plusieurs services

Circuits modélisés pouvant être modifiés en cours

Associés à des captures d’images, de documents par scanners

Une application workflow automatise une séquence d’actions, d’activités ou de tâches dans un processus donné : une demande d’achats, le règlement d’un litige, une mise au contentieux, le règlement d’un sinistre… Le workflow comprend également les outils nécessaires pour connaître l’état de chaque instance du processus ainsi que pour gérer le déroulement du processus. Le champ du workflow est donc vaste et les problématiques sont de complexité variable. La classification donnée ici est tirée de l’ouvrage Introduction to Groupware, Workflow and Workgroup Computing de Setrag Khoshafian et Marek Buckiewicz (John Wiley & Sons, Inc.).

– Workflow administratif, – Workflow ad hoc, – Workflow de production.

Lotus propose une classification assez proche qui est commentée ensuite.

Workflow administratif

Ces applications sont basées sur les capacités des logiciels de messagerie à intégrer des formulaires répondant à quantité de besoins simples, courants et répétitifs : demande de congés, demande d’achat de fournitures… Les fonctions supportées par un workflow administratif se caractérisent par des formulaires, leur routage, des itérations limitées, une gestion réduite des alarmes et des notifications.



Workflow ad hoc Le workflow ad hoc supporte habituellement des processus à l’intérieur d’un projet : le circuit est plus complexe que celui suivi par un formulaire dans un workflow administratif : un processus peut s’appuyer sur plusieurs documents circulant entre de nombreux acteurs. Un document peut itérer entre un ou des acteurs avant de poursuivre le processus (négociations, validation, vérification). Des alarmes et des notifications par courrier électronique identifient pannes et retards. Les utilisateurs disposent d’une marge d’autogestion pour résoudre les cas peu courants.

Workflow de production Les workflows de production supportent des processus complexes et critiques pour le bon fonctionnement de l’entreprise. Un grand nombre d’acteurs interviennent dans la chaîne. Le système ne pouvant être complètement prédictible, il faut pouvoir modifier dynamiquement le modèle et les règles qui pilotent un processus afin de réagir à un événement imprévu ou peu fréquent. Ces applications s’accompagnent de capture d’informations (courrier entrant scanné par exemple) ce qui génère un volume très important d’informations de valeur. L’application de prêt précédente peut faire l’objet d’un workflow de production en détaillant et en formalisant davantage les étapes du processus.

Classification proposée par Lotus Lotus propose une classification prenant en compte la technologie utilisée :

– Base de documents partagée : flexibilité, – Processus décrits précisément : structuration forte.

Ceci amène trois classes de workflow :

– Collaboratif : rassemble le workflow administratif, le workflow ad hoc et les techniques de travail en groupe,

– Structuré : il est proche du workflow de production. Un workflow standard décrit de façon précise les processus standardisés et récurrents. L’utilisateur intervient pour gérer les exceptions par déviation du processus standard,

– Semi-structuré : comme son nom l’indique, il est à mi-chemin entre le collaboratif et le structuré. La complexité est gérée par un découpage en activités chaînées (impliquant un nombre prédéfini d’acteurs) et des techniques de travail de groupe.



Domino Workflow Domino Workflow

Conception par interface graphique

Développement

Maintenance

Séparation des composants

Logique : la programmation

Les objets : données

Visualisation de l’état d’un processus

Interface graphique

Prise en compte de workflows complexes

Domino Workflow est une application Lotus Notes qui supporte le développement de workflows ad hoc et de production : analyse et conception de l’application, exécution, visualisation d’un processus en cours.

Domino Workflow architect Le concepteur d’application modélise les processus depuis une interface graphique. Les modifications de processus se font également depuis cette interface. Les éléments de conception sont enregistrés dans une base Design Repository.

Domino Workflow engine Ce composant exécute l’application. Les composants sont nettement séparés : Process Definition décrivant les processus, Organization Database décrivant l’organisation de l’entreprise, Application Database qui contient notamment les documents circulant manipulés dans les processus. Dans Application Database, les règles du workflow exprimées dans les deux autres bases – Process Definition et Organization – sont matérialisées et s’appliquent sur les objets du workflow.

Domino Workflow viewer Ce composant permet de visualiser graphiquement un processus en cours pour connaître son état d’avancement.

Documentation Le RedBook using Domino Workflow – SG245963 – présente en détail l’architecture de Domino Workflow. D’autres documents et une version d’évaluation sont disponibles sur http://www.lotus.com/home.nsf/welcome/domworkflow.



Application de suivi de tâches Application de suivi de tâches

Champ : suivi des tâches distribuées pendant les réunions

L’application de suivi de réalisation de tâches qu’il s’agit de réaliser a été présentée dans module Méthodologie élémentaire. C’est un workflow très simple qui parcourt les techniques de programmation utilisées dans ce type d’application en les reliant à une méthode générale d’analyse fondée sur UML. Les grandes lignes sont rappelées brièvement ici.

Domaine et objectifs Cette application est une extension de l’application de suivi de réunion et se trouve dans le même domaine : elle intéresse toutes les personnes participant à des projets de développement d’applications.

L’objectif est d’améliorer la distribution, le suivi et la publication des travaux nécessaires à l’avancement du projet : il s’agit essentiellement de production de documents de type présentations, rassemblement d’informations nécessaires à l’avancement du projet.

Les acteurs Projet Suivi de réunion

Acteur Description

Exécutant Un exécutant – la personne affectée – est responsable de l’achèvement de la tâche qui lui a été attribuée et en rend compte au responsable de la réunion.

Organisateur Le compte rendu de réunion comporte une liste de tâches à effectuer. L’organisateur affecte une tâche à un exécutant. Il valide également le résultat du travail et décide de diffuser ou non le document créé.



Diagramme de cas d’utilisation

Projet Suivi de tâches

Cas utilisation Description

Attribuer une tâche

L’objectif est de définir une tâche et de l’attribuer à un exécutant.

Exécuter la tâche

L’objectif est de communiquer le document qui concrétise la réalisation de la tâche.

Contrôler le travail

L’objectif est de valider le document produit et d’en décider ou non la publication

Diagramme de classes Deux types de documents sont représentés comme autant de classes :

– Compte rendu, – Tâche.

Les opérations applicables aux tâches – méthodes dans la terminologie OO – sont symbolisées dans la partie inférieure du cadre représentant la classe Tâche. Ce sont Notifier(), Terminer(), Corriger(), Publier() et Abandonner().



Projet Suivi de tâches

Classe Tâche

Opération Description

Notifier() Actionnée par l’organisateur, si la notification n’a pas déjà été envoyée. La tâche passe de l’état En attente à En cours. L’exécutant affecté à une tâche reçoit un message dans sa base Courrier avec un lien sur la tâche à effectuer.

Terminer() Actionnée par l’exécutant sur une tâche qui lui est affectée et qui est En cours.. La tâche est à l’état En cours et passe à l’état Effectuée.

Corriger() Actionnée par l’organisateur, sur une tâche Effectuée. La tâche passe de l’état Effectuée à En cours.

Approuver() Actionnée par l’organisateur, sur une tâche Effectuée. La tâche passe de l’état Effectuée à Publiée. Le document produit est visible de tous.

Abandonner() Actionnée par l’organisateur, sur une tâche Effectuée. La tâche passe de l’état Effectuée à Abandonnée.

Diagramme d’états-transitions Ce diagramme décrit les états successifs d’une tâche. L’attribut Statut de la classe Tâche prend les valeurs En attente, En cours, Effectuée, Publiée et Abandonnée. L’état initial est symbolisé ci-dessous par un cercle plein au départ et l’état final par deux cercles concentriques.

– Chaque rectangle symbolise un état et le texte sur la transition indique l’acteur – ou l’événement – à l’origine de la transition et l’action effectuée.



Le routeur de messagerie Le routeur de messagerie

Messager

Routeur

MAIL.BOX mail\aplanchou.nsf

Notifier un acteur lorsqu’un travail est en retard, publier un document dans une base s’appuient communément sur le mécanisme de routage de courrier de Notes. Ce paragraphe décrit le mécanisme de fonctionnement du routeur sur le serveur.

Dépôt d’un message Un message (un document) est déposé depuis le client Notes dans la boîte aux lettres du serveur – MAIL.BOX – par la composante Messager du client. Ce message est un document Notes qui contient au minimum le nom du destinataire : une personne, une base Courrier en arrivée – module Créer des agents/Agent courrier –, un groupe. Le messager vérifie que le destinataire est recensé dans l’annuaire du domaine. Le message est déposé depuis la base Courrier de l’utilisateur ou depuis une application de workflow par un bouton ou un agent qui tourne sur le poste client ou sur le serveur.

Distribution d’un message Le routeur est une tâche du serveur qui examine périodiquement la MAIL.BOX et qui est chargée de la distribution des messages (documents) déposés. Par consultation de l’annuaire Domino du domaine – names.nsf – sur le serveur, le routeur détermine l’emplacement de la base Courrier d’un utilisateur – onglet (Messagerie) du document Personne de l’utilisateur – ou de la base correspondant à la base Courrier en arrivée – onglet (Informations sur la base) du document Base Courrier en arrivée.

Si la base est trouvée, le message (document) est déposé, sinon un avis de non-distribution est retourné à l’expéditeur.

Si le destinataire est hébergé sur un autre serveur, le routeur ouvre une session sur le serveur de destination et dépose le message (document) dans la MAIL.BOX de ce serveur. Si le serveur distant ne peut pas être atteint directement, le routeur cherche la route la plus courte et dépose le message (document) dans la MAIL.BOX du premier nœud de la route.



Envoyer une notification à un utilisateur

Fonction @MailSend dans une formule de bouton, d’événement

Sans paramètres : champ SendTo obligatoire@MailSend

Avec paramètres : paramètre envoiA obligatoire@MailSend(envoiA ; copieA; copieCacheeA ;objet ; remarques ; champs ; [Indicateurs])

envoiA, copieA, copieCacheeA : destinataire(s)

objet, remarques : le message

champs : expression contenant la liste des champs dudocument à inclure dans le message

[Indicateurs] : [IncludeDocLink], [Sign], [PriorityLow], ...

Envoyer une notification à un utilisateur

Une notification est envoyée à un utilisateur dans sa base courrier :

– Lorsqu’une tâche urgente le sollicite, – Lorsqu’une tâche est en retard.

Remarque Il est conseillé d’utiliser la base Courrier de l’utilisateur uniquement pour les cas d’exception. En effet, si un grand nombre de notifications sont envoyées par courrier, l’utilisateur devra gérer et classer ces notifications. Il est plus rationnel de lui préparer des vues privées dans une base – l’équivalent de bannettes – dans lesquelles il trouvera les tâches à effectuer préclassées. Une notification est générée avec la fonction @MailSend et contient habituellement un lien – LienDoc – avec le document, ce qui permet à l’utilisateur d’ouvrir le document à partir du message de notification. Cette fonction a été vue dans le module

Créer des agents/Agent courrier.

@MailSend sans paramètres Le destinataire du document est enregistré dans un item nommé SendTo – nom réservé – au minimum. L’intégralité du document est envoyée au destinataire. Cette méthode est utilisée surtout pour envoyer des documents à une base de workflow définie comme base Courrier en arrivée.

@MailSend avec paramètres Le destinataire du document est précisé comme paramètre de la fonction. Il est aussi possible de créer un LienDoc avec l’indicateur [IncludeDocLink], de copier le contenu de certains items du document dans le message. Cette méthode est utilisée pour envoyer une notification à un utilisateur dans sa base Courrier.



Envoyer un document

La base de destination contient un masque pouvant afficher ledocument

Champ sendTo obligatoire

Le destinataire est un utilisateur ou une base

Deux techniques

Le masque présente un dialogue d’envoi

Le champ MailOptions détermine l’envoi

Envoyer un document

L’envoi d’un document en entier se fait avec @MailSend sans paramètres. Il peut également être programmé avec l’une des deux techniques suivantes :

– l’affichage d’un dialogue à l’enregistrement du document par une propriété du masque,

– l’utilisation d’un champ MailOptions dans le masque qui laisse choisir l’utilisateur ou force l’envoi du document – ou l’interdit –.

Dans les deux cas, le champ SendTo détermine le nom du ou des destinataires.

Dialogue par propriétés du masque

Designer 6.0 Démonstrations/Masque Routage\Envoi document

Cliquer sur cette icône ou commande Conception/Propriétés du masque...

Cliquer sur l’onglet (Défaut).

• <A la fermeture> : cliquer ⌧Afficher la boîte de dialogue d’envoi de courrier

• Créer un champ de type Noms et le nommer SendTo

Cliquer sur cette icône, ou commande Conception/Prévisualiser dans Notes.

• Saisir un destinataire puis sauvegarder et fermer le document

La boîte de dialogue s’affiche :



• Cliquer (Envoyer uniquement) ou (Envoyer et enregistrer)

Le document apparaît dans la base Courrier du destinataire.

Remarque Si le document n’est pas conçu comme un message, il ne sera que partiellement affiché dans la base Courrier. Au minimum, le nom de l’expéditeur apparaîtra. Le masque Memo de la base Courrier affiche le contenu des items From, SendTo, CopyTo, BlindCopyTo, Subject et Body. Si un item est absent, le champ n’affiche rien. Cette technique est donc applicable si le document envoyé contient les items reconnus par le masque Memo ou si la base destinataire n’est pas une base de courrier utilisateur mais une base d’une application de workflow.

Champ MailOptions Ce champ du masque peut prendre les valeurs :

– ″0″ : bloque l’envoi du document, – ″1″ : force l’envoi du document par routeur de messagerie.

Designer 6.0 Démonstrations/Masque Routage\Envoi document par MailOptions

Champ modifiable L’utilisateur se voit proposer le choix par bouton radio, par exemple. L’utilisation d’un pseudonyme sépare le texte proposé à l’utilisateur de la valeur enregistrée.

Champ calculé Le champ est positionné par une formule en dehors de l’événement valeur du champ :

– les contrôles détectent une anomalie, – le document a déjà été envoyé, – l’état du document – sa position dans le processus – ne demande pas son routage, – le document doit être routé.

FIELD MailOptions := ″0″ ;

MailOptions

Bouton radio

Choix



Utiliser les rôles Utiliser les rôles

Le rôle – au sens Domino/Notes – détermine une catégoried’utilisateurs

Qui initialise un processus : par exemple, le manager

Qui peut intervenir à tout moment dans n’importe quel processus

Dans la LCA (liste de contrôle d’accès) de la base

Ajouter le rôle

L’affecter à une personne ou un groupe

Dans l’application : utiliser @UserRoles

Pour connaître la liste des rôles de l’utilisateur courant

Montrer ou cacher des boutons, des vues, des paragraphes...

Le rôle correspond à un acteur identifié dans les diagrammes de cas d’utilisation. L’acteur a un rôle dans l’application qui est souvent traduit par un rôle dans la LCA – Liste de contrôle d’accès de la base –. Pour éviter les confusions sémantiques, nous parlerons respectivement du rôle (fonction) et du rôle (LCA).

La création et l’utilisation d’un rôle (LCA) dans la LCA d’une base ont été vues dans les modules Gérer l’accès à l’application/LCA : le rôle et Gérer l’accès à l’application/Droits : fonctions @ spéciales. L’utilisation du rôle (LCA) dans une application de workflow est présentée ici au travers d’exemples.

Une catégorie d’utilisateurs Le rôle (LCA) est inutile – ou inutilisable – dans un certain nombre de cas tels que :

– l’ensemble des utilisateurs a le même rôle (fonction) : par exemple, dans le cas d’un formulaire de demande de congés, tout le monde a le droit de demander à partir en congés, donc a le rôle (fonction) d’initialiser le processus,

– une catégorie d’utilisateurs a un rôle (fonction) de faciliteur et doit pouvoir modifier n’importe quel document de la base. Il suffit de leur donner l’accès Editeur dans la LCA de la base pour que ce besoin soit satisfait,

– le rôle (fonction) de responsable hiérarchique est défini par un lien de dépendance recopié dans un document : par exemple, dans le cas de la demande de congés, le nom du manager qui accepte/refuse la demande est copié dans le formulaire au moment de la création de ce dernier. Du point de vue de l’application de workflow Notes, le rôle (fonction) est déterminé par le contexte du document.

Le rôle (LCA) est bien adapté dans des cas tels que :

– un groupe limité d’utilisateurs dispose du rôle (fonction) d’initialiser un processus, par exemple, la création d’une tâche, la création du dossier de prêt…

– un groupe limité d’utilisateurs modifie les règles de gestion d’une application – listes de mots-clés, de codes… –, et accède à des vues réservées, peut créer ou modifier des documents particuliers,



– un rôle (LCA) de dépannage – qui correspond à un rôle (fonction) informatique et non pas de l’application – peut être utile pour afficher les valeurs de champs normalement cachés, ou pour des documents de visibilité restreinte.

Création du rôle dans la LCA Le rôle (LCA) est créé dans la LCA de la base sous forme d’une chaîne de caractères qui sera testée ensuite dans l’application. Il faut donc avoir un standard pour la casse (majuscules/minuscules). Le rôle (LCA) est ensuite affecté à une/des personnes ou groupes.

Remarque L’application peut connaître les groupes auxquels appartient l’utilisateur courant, donc effectuer des tests sur ces noms. Il est préférable d’associer les groupes à des rôles (LCA) pour que l’application ne soit pas liée à une nomenclature de groupe : il y a séparation entre la logique de l’application et la façon dont elle sera mise en production. • Cliquer sur une entrée, puis sélectionner le rôle

Utiliser @UserRoles @UserRoles retourne la liste des rôles (LCA) de l’utilisateur courant. La fonction @IsMember teste si une chaîne de caractères est membre d’une liste. @IsMember ("[Gestionnaire]" ; @UserRoles ) ; La fonction @IsMember retourne True si la chaîne “[Gestionnaire]” fait partie de la liste @UserRoles.

Initialiser un processus L’initialisation d’un processus consiste le plus souvent à créer un document depuis un bouton. Dans l’exemple qui suit, le bouton (Création tâche) est visible si l’utilisateur courant a le rôle [Organisateur].

• Afficher les propriétés du bouton

Cliquer sur l’onglet (Masquer).

Accès à des vues réservées Certaines vues sont destinées aux utilisateurs ayant un rôle (LCA). Par exemple, la vue Taches\1. Manager est visible des utilisateurs ayant le rôle [Organisateur].

• Afficher les propriétés de la vue, puis cliquer sur l’onglet (Sécurité)

• Désélectionner Tout utilisateur ayant au moins l’accès Lecteur

• Sélectionner le rôle [Organisateur]

Rôle apparaissant entre crochets

Rôle sélectionné



Modifier un document sous condition Modifier un document sous condition

Les utilisateurs ont l’accès Auteur dans la LCA

Les champs Auteurs précisent qui peut modifier un document

Liste d’utilisateurs

Liste de rôles

Les champs Auteurs sont

Modifiables par le propriétaire du document,(du processus) : délégation de l’accès Auteur

Calculés d’après l’état du document dansle processus : un document archivé n’estplus modifiable

Propriétaire

Délégation

Les utilisateurs qui ont besoin de créer et/ou de modifier des documents ont un droit d’accès Auteur dans la LCA de la base. Le droit d’accès Editeur – qui permet de créer des documents et de modifier n’importe quel document – est trop élevé et ne devrait être donné qu’à un groupe restreint d’utilisateurs gérant la base. L’accès Auteurs a été abordé dans le module Gérer l’accès à l’application/Document : accès Auteur. Ce paragraphe présente les champs de type Auteurs et la manière d’en modifier le contenu dans le contexte d’une application de workflow.

Contenu des champs Auteurs Les champs de type Auteurs précisent quels sont les utilisateurs – ayant le droit d’accès Auteur dans la LCA de la base – qui peuvent modifier le document courant. Notes prend en compte l’ensemble des champs Auteurs pour déterminer ces droits. Les champs Auteurs peuvent contenir des noms de personnes, des noms de groupes, des rôles (LCA).

C’est une bonne pratique que de prévoir un champ de type Auteurs, calculé à la création et qui contient un rôle (LCA) pour des besoins de dépannage et qui peut être également affecté aux serveurs. Le rôle peut s’appeler [Admin] par exemple, le rôle [Gestionnaire] désignant plutôt les utilisateurs qui modifient les règles de gestion de la base.

Modification des champs Auteurs Dans l’exemple d’application proposé ici, il y a deux personnes identifiées qui accèdent à un document en modification :

– Le manager qui a créé la tâche, et qui doit pouvoir la modifier ensuite, notamment pour pouvoir déclarer la tâche abandonnée ou approuvée,

– La personne désignée pour effectuer la tâche et qui devra modifier le document entre le moment où la tâche est en cours et celui où elle est publiée ou abandonnée.



Utilisation de deux types de champs Il apparaît donc que la présence du nom de la personne affectée dans un champ de type Auteurs n’est pas permanente. Il s’ensuit que le champ modifiable dans lequel le manager indique la personne affectée ne peut être de type Auteurs et sera plutôt de type Noms. Ce nom devra être dupliqué dans un champ de type Auteurs pour en être retiré une fois le travail accompli.

• Créer un champ de type Noms et modifiable

• Créer un champ de type Auteurs, calculé à la création, caché, supportant des valeurs multiples

Mise à jour du champ Auteurs La mise à jour se fait dans l’événement onSubmit (QuerySave) par exemple, d’après l’état du document déterminé par le champ Statut, qui utilise des pseudonymes.

Statut En attente En cours Effectuée Publiée Abandonnée

Auteurs Organisateur : Affecte

Organisateur: Affecte

Organisateur Organisateur Organisateur

La formule qui met à jour le champ AuteursDoc – de type Auteurs – sera : FIELD AuteursDoc := @If ( Statut = "EA": "EC" ; Organisateur : Affecte ; Statut = "" : "TE" : "AP" : "AB" ; Organisateur ; AuteursDoc) ;

Le champ contenant le nom de l’organisateur est lui aussi de type Noms. De cette manière, la faculté est donnée de retirer l’accès Auteur à l’organisateur, par exemple lorsque l’étude est publiée, elle sera gérée par un bibliothécaire.

Remarque Le masque évalue une seule fois la formule de l’événement valeur du champ AuteursDoc puisque celui-ci est calculé à la création. La valeur du champ est déterminée ensuite à l’extérieur du champ. Le type calculé à la création est recommandé dans cette situation.

Type Noms

Modifiable

Type Auteurs

Calculé à la création

Autoriser entrées multiples

Formule : le nom du champ lui-même



Déterminer la visibilité d’un document Déterminer la visibilité d’un document

Les utilisateurs ont l’accès minimum Lecteur dans la LCA

Les champs Lecteurs précisent qui peut voir un document

Liste d’utilisateurs, de serveurs

Liste de rôles

Les champs Auteurs permettent de voir également un document

Les champs Lecteurs sont

Modifiables par le propriétaire du document,(du processus) : document à visibilité réduite

Calculés : un bouton (Privé) renseigneun champ Lecteurs avec le nom de l’utilisateurcourant

Privé

Les utilisateurs qui ont besoin de lire des documents ont un droit d’accès Lecteur au minimum dans la LCA de la base. Le droit générique de lecture de n’importe quel document peut être restreint en utilisant des vues réservées et des formules de sélection comme cela a été décrit dans le paragraphe Utiliser les rôles. Une autre technique consiste à utiliser des champs de type Lecteurs listant les personnes, groupes et rôles pouvant lire le document quelle que soit la vue dans laquelle il apparaît. L’accès Lecteur pour un document a été abordé dans le module Gérer l’accès à l’application/Document : accès Lecteur. Ce paragraphe présente les champs de type Lecteurs et la manière d’en modifier le contenu dans le contexte d’une application de workflow.

Contenu des champs Lecteurs Les champs de type Lecteurs et Auteurs précisent quels sont les utilisateurs – ayant le droit d’accès Lecteur minimum dans la LCA de la base – qui peuvent voir le document dans une vue et l’afficher. Notes prend en compte l’ensemble des champs Lecteurs et Auteurs pour déterminer ce droit. Ce schéma fonctionne dès lors qu’il y a un champ de type Lecteurs non vide.

C’est une bonne pratique que de prévoir un champ de type Auteurs, calculé à la création et qui contient un rôle (LCA) qui peut être également affecté aux serveurs. Le rôle peut s’appeler [Admin] par exemple. De cette façon, il est certain que les serveurs pourront toujours voir les documents pour les répliquer ou lors de l’exécution d’un agent.

Remarque Les champs de type Lecteurs sont une protection par programmation des documents d’une base. Ils offrent une protection convenable des documents confidentiels si le serveur est sécurisé. Cependant, il est toujours possible de faire sauter les verrous gérés par programmation en accédant au disque contenant la base sans passer par Domino. Le chiffrement offre un degré de protection supérieur.



Modification des champs Lecteurs

Document privé Le créateur du document est le seul à voir le document parce que ce dernier est en cours d’élaboration et que le rendre visible serait source de confusion par exemple. Le plus simple est de créer un bouton d’action avec deux libellés (Marquer privé)/(Marquer public). Lorsque le libellé est (Marquer privé), un clic restreint la visibilité du document à son propriétaire puis le libellé devient (Marquer public). Un nouveau clic rend le document visible à tous. Le bouton est visible avec le rôle (LCA) [Organisateur].

• Créer un champ LecteursDoc de type Lecteurs, calculé, caché, supportant des valeurs multiples

• Créer un bouton d’action (Marquer privé)/(Marquer Public)

• Le libellé dépend du contenu du champ de type Lecteurs. Si le champ est vide, le libellé est Marquer privé, sinon il est Marquer public

@If( @IsNull(LecteursDoc) ; "Marquer privé" ; "Marquer public")

• Cliquer sur l’onglet (Masquer) dans le dialogue des propriétés

• Cliquer ⌧Cacher l’action si la formule est vérifiée et taper la formule ! ( @Contains (@UserRoles ; "[Organisateur]" ) )

Le bouton doit être visible si l’utilisateur courant a le rôle [Organisateur]. La négation de cette condition indique quand le bouton doit être caché.

• <Evénement Click> : taper la formule @If(@IsNull(LecteursDoc) ; FIELD LecteursDoc := Organisateur; FIELD LecteursDoc := Null ); @Command([RefreshHideFormulas]);

LecteursDoc reçoit le nom de l’organisateur. La commande @ rafraîchit les formules de masquage des boutons ce qui remplace le libellé Marquer privé par Marquer public.

Document partagé à visibilité restreinte Le créateur du document désire le partager avec un groupe restreint d’utilisateurs pendant la phase d’élaboration, ou parce que le document est de diffusion limitée.

• Créer un bouton d’action (Partage restreint)

• Afficher les propriétés du bouton, puis cliquer sur l’onglet (Masquer)

• Cliquer ⌧Cacher l’action si la formule est vérifiée et taper la formule ! ( @Contains (@UserRoles ; "[Organisateur]" ) )

Le bouton doit être visible si l’utilisateur courant a créé ce document.

• <Evénement Click> : taper la formule LecteursAutorises := @PickList([Name]) ; FIELD LecteursDoc := Organisateur : LecteursAutorises ; @Command([RefreshHideFormulas]) ;

LecteursDoc reçoit le nom de l’organisateur et les noms choisis dans l’annuaire. La commande @ rafraîchit les formules de masquage des boutons.



Créer une section d’accès contrôlé Créer une section d’accès contrôlé

L’utilisateur est Auteur

Sur le document

Il est Editeur

Sur des sections d’accès contrôlédéfinies dans le masque

Plusieurs utilisateurs

Modifient dans le même document

Une section (un paragraphe) propreà chacun

Autre solution : sous-masque calculéou masque déterminé par une formule de vue

Les utilisateurs qui ont besoin de créer et/ou de modifier des documents ont un droit d’accès Auteur dans la LCA de la base et sont présents dans des champs Auteurs des documents. A l’intérieur d’un document, la section d’accès contrôlé détermine qui peut modifier telle ou telle partie du document. La section d’accès contrôlé a été vue dans le module Gérer l’accès à l’application/Masque : section d’accès contrôlé. Ce paragraphe présente cette technique dans le contexte d’une application de workflow. L’alternative consistant à utiliser des sous-masques est vue ensuite.

Conception des sections d’accès contrôlé

Organisation du masque Le masque doit être organisé pour regrouper tous les champs modifiables par une catégorie d’utilisateurs. Dans l’application exemple, il y a principalement deux intervenants : l’organisateur et l’employé affecté à la tâche. L’organisateur détermine les règles de gestion du document et l’employé doit remplir la partie destinée à recevoir le résultat du travail, puis déclarer la tâche effectuée.

Formule d’accès Le découpage étant effectué, la formule d’accès d’une section d’accès contrôlé doit retourner la liste des éditeurs de la section, c’est-à-dire la liste des personnes, groupes et rôles ayant le pouvoir de modifier les champs modifiables inclus dans la section. Les items dont le contenu sert aux calculs – les règles – sont extérieurs à la section – le contenant – pour éviter les blocages. Par ailleurs, il est prudent d’inclure systématiquement un rôle de dépannage – [Admin] dans les exemples précédents – pour corriger les blocages éventuels.

• Créer la section d’accès contrôlé, module Gérer l’accès à l’application/Masque : section d’accès contrôlé

• Clic droit sur le titre de la section puis commande Propriétés de la section…

Cliquer sur l’onglet (Formule).



• <Type> : sélectionner Calculé : la liste des éditeurs est calculée à partir de valeurs provenant d’autres champs

• <Formule d’accès> : taper une formule qui retourne la liste des éditeurs possibles : noms ou groupes contenus dans un champ, rôles. Chaque élément de la liste est séparé du suivant par le caractère deux-points ( : ) – pour la section d’accès contrôlé concernant l’organisateur : Organisateur : ″[Admin]″ – pour la section d’accès contrôlé concernant la personne affectée : Affecte : ″[Admin]″

Mise à jour d’un champ depuis deux sections Un champ Statut pilotant l’état du document peut être mis à jour depuis deux sections. Une solution possible consiste à utiliser un bouton – zone sensible d’action – ou un champ de saisie supplémentaire dont le contenu est affecté au champ Statut. Dans l’exemple d’application, l’état du document peut être modifié par :

– l’organisateur : il gère les valeurs En attente, En cours, Publiée, Abandonnée, – l’employé affecté : il gère la valeur Terminée.

Une solution consiste à créer deux champs de saisie séparés – par exemple orgStatut et empStatut –, les listes de valeurs étant calculées d’après l’état actuel du document. La formule de l’événement onSubmit (QuerySave) se charge d’écrire le résultat de la saisie dans le champ Statut lequel est calculé (Formule d’événement valeur : Statut), et vide les deux champs de saisie intermédiaires. FIELD Statut := @If ( !@IsNull(orgStatut) ; orgStatut ; !@IsNull(empStatut) ; empStatut ; Statut) ; FIELD orgStatut := NULL ; FIELD empStatut := NULL ;

Utilisation de sous-masques L’utilisation de sous-masques a été vue dans le module Gérer l’accès à l’application/Masque : section d’accès contrôlé. Une application de ce principe est proposée ici en remplacement des sections d’accès contrôlé.

Création des sous-masques L’ensemble des champs modifiables par l’organisateur doit être simplement affichable pour l’employé affecté et inversement. Il faut donc créer deux sous-masques – autant de sous-masques que d’acteurs – pour cet ensemble :

– un sous-masque smTacheOrganisateur destiné à l’organisateur qui contient tous les champs qu’il peut modifier, les autres champs étant calculés à l’affichage,

– un sous-masque smTacheAffecte destiné à l’employé affecté qui contient tous les champs qu’il peut modifier, les autres champs étant calculés à l’affichage.

Formule d’insertion La formule d’insertion du sous-masque sera du type : @If (@IsNewDoc ; "smTacheOrganisateur" ; @Name([CN];@UserName) = @Name([CN]; Organisateur) ; "smTacheOrganisateur" ; "smTacheAffecte" ) ;

Si le document est nouveau ou si l’utilisateur courant est l’organisateur, le sous-masque smTacheOrganisateur est inséré, sinon c’est le sous-masque smTacheAffecte. Le document est protégé par le champ AuteursDoc de type Auteurs et une personne doit être présente dans ce champ pour modifier les champs dans un sous-masque.



Contrôler l’état d’un document Contrôler l’état d’un document

Le diagramme d’états-transitions documente les états d’undocument dans un processus

Les états sont les valeurs d’un indicateur

L’indicateur (un item) est mis à jour

Par bouton : (Approuver), ...

Par un agent : traitement de clôture...

Pour un état déterminé

Certaines transitions internes et de sortie sont possibles à partirde l’état actuel, des valeurs d’autres items, du temps

Des transitions internes sont mémorisées : notification envoyée...

Activité (traitement récurent) : rappel périodique (date)...

Le diagramme d’états-transitions a mis en évidence les états de gestion d’un document : ceux qui ont un sens pour les utilisateurs. Le passage d’un état vers un ou d’autres états se fait par des transitions – sortie d’un état et entrée dans le suivant – qui correspondent à des actions de l’utilisateur ou à des actions déclenchées automatiquement en fonction du temps le plus souvent.

L’état est un attribut de la classe entité qui correspond à un item spécifique du document – par exemple Statut – dans Domino. Les valeurs de cet item mémorisent les positions successives du document dans le processus. Lorsque le document est dans un état donné, deux types de transitions et des activités sont habituellement identifiés :

– Transitions de sortie : l’utilisateur agit en cliquant sur un bouton ou un agent traite le document et le traitement change la valeur de l’état. Ces transitions sont figurées sur le diagramme d’états-transitions par le texte attaché à la flèche matérialisant la transition.

– Transitions internes : toute une série de traitements peuvent se dérouler sans pour autant modifier l’état du document. Ce sont par exemple des notifications envoyées aux acteurs, ou des relances ou un calcul effectué périodiquement. Il peut être nécessaire de mémoriser certains traitements pour être sûr qu’ils ne s’exécuteront qu’une seule fois, par exemple une notification. Il faudra alors créer des états internes non visibles de l’utilisateur. Ces transitions se documentent également dans le diagramme d’états-transitions.

– Activité : il s’agit de traitements récurrents – notés Do dans un diagramme UML – qui ne peuvent se rattacher qu’à l’état et qui cessent quand le document sort de l’état. Ce peut être une mise à jour périodique d’un item (le calcul d’un âge), des rappels périodiques envoyés, des requêtes vers une source de données externe pour synchronisation, etc.

Le scénario va s’intéresser ici à la mise à jour de l’indicateur d’état Statut suite à l’enregistrement du document de tâche – la transition s’effectue à partir de valeurs actuelles et du facteur temps – et à la mise à jour d’un indicateur d’état interne suite à l’envoi d’une notification.



Création d’un indicateur L’indicateur d’état est un item dont le contenu est déterminé par des formules n’appartenant pas à des événements attachés au champ correspondant dans le masque : formules d’événement Clic de bouton, événement onSubmit (QuerySave) du masque, agent, etc. Pour définir l’indicateur dans le masque :

• Créer un champ Calculé à la création, par exemple Statut, de type Texte le plus souvent

• <Evénement valeur du champ> : taper Null ou le nom du champ, ici Statut, si la chaîne de caractères vide est requise au départ ou taper la valeur correspondant au premier état du document, par exemple En attente pour la tâche

Remarque Une bonne pratique consiste à associer pour un état un libellé affiché à l’utilisateur et un code testé par formule pour une plus grande souplesse d’évolution de l’application.

Lorsque des indicateurs n’ont pas besoin d’être visibles de l’utilisateur, une pratique courante consiste à les grouper en tête du masque dans un paragraphe caché. Les applications écrites par Lotus utilisent une police de caractères avec un corps de 9, normal et rouge et des commentaires placés à côté des indicateurs. De la même façon, les indicateurs internes attachés à des transitions internes sont créés comme champs Calculés à la création.

Il peut être pratique de créer des champs calculés à l’affichage qui déterminent en fonction de l’état d’un document, de l’utilisateur connecté, de la dimension temps, quels sont les boutons devant être affichés, les libellés de ces boutons, les transitions possibles.

Mise à jour d’un indicateur d’état

Evénement onSubmit (QuerySave) Reprenons l’exemple du Statut de la tâche qui évolue selon le schéma :


Pseudonyme EA EC EF PU AB

Dans le paragraphe Créer une section d’action contrôlée, l’organisateur agit sur le Statut depuis un champ de saisie orgStatut et l’employé fait de même depuis un autre champ empStatut. L’événement valeur de Statut est : FIELD Statut := @If ( !@IsNull(orgStatut) ; orgStatut ; !@IsNull(empStatut) ; empStatut ; Statut) ; FIELD orgStatut := NULL ; FIELD empStatut := NULL ;

Une variante est proposée ici, qui consiste à ne pas calculer Statut depuis l’événement Valeur : c’est pourquoi il a été transformé en Calculé à la création. Par ailleurs, les spécifications ont évolué et disent que si le Statut de la tâche est Effectuée et que la DateFinPrevue est dépassée alors le Statut passe à Publiée (PU). La programmation est effectuée dans l’événement onSubmit (QuerySave) du masque. FIELD Statut := @If (!@IsNull(orgStatut) ; orgStatut ; !@IsNull(empStatut) ; empStatut ; Statut) ; FIELD Statut := @If (Statut = "EF" & DateFinPrevue < @ToDay ; "PU" ; Statut) ;



FIELD orgStatut := NULL ; FIELD empStatut := NULL ;

Dans la pratique, la mise à jour de Statut se fait à l’extérieur du champ pour une plus grande souplesse quant au choix du moyen et du moment où elle est effectuée : onSubmit, bouton ou agent.

Evénement Clic de bouton Le scénario proposé ici illustre la mise en place d’un indicateur lié à une transformation interne : l’organisateur notifie l’employé affecté en pressant sur un bouton prévu à cet effet. La notification ne doit être envoyée qu’une seule fois et est contrôlée avec un indicateur notifAffecte qui contient la date et l’heure de l’envoi. msg := "Merci d’intégrer cette tâche à votre plan de travail" ;@If ( @IsNull(notifAffecte) ; @Do( @MailSend(Affecte;NULL;NULL;TitreTache;msg;NULL; [IncludeDocLink] ) ; FIELD notifAffecte := @Text(@Now)) ; @Success);

Cette séquence pourrait aussi bien être incorporée dans l’événement onSubmit (QuerySave) pour une notification systématique lorsque le Statut est En cours si les spécifications le prévoient ainsi.

Mise en place d’une activité Le scénario proposé ici illustre la mise en place d’une activité de relance automatique : – tous les jours – lorsque la tâche est dans l’état En cours et que la date de fion prévue est dépassée.

Evénement Action d’agent Cette relance est effectuée par un agent planifié tous les jours, par exemple à 5h du matin, sur le serveur. msg := "La base de suivi ne contient pas d’information de fin de la tâche qui vous a été confiée." + @NewLine + "La date prévue initialement " + @Text(DateFinPrevue) + " est dépassée. " + @NewLine + "Merci de terminer votre travail et de mettre à jour l’information." ; @If ( Statut = "EC" & DateFinPrevue < @ToDay ; @MailSend(Affecte;NULL;NULL;TitreTache;msg;NULL; [IncludeDocLink] ) ; @Success);



Contrôler l’accès à une vue Contrôler l’accès à une vue

Une vue partagée est visible

Par tout utilisateur ayant au moins l’accès Lecteur dans la LCA

Par un utilisateur désigné : nom, rôle, nom de groupe

Une vue privée est visible

De l’utilisateur qui la crée

De l’utilisateur qui ouvre une vue partagée devenant privée

Utilisation de la méthode

Vues réservées à l’acteur gestionnaire d’application : lesdocuments en conflit de réplication, les listes de codes…

Vues réservées à d’autres acteurs identifiés par un rôle dans laLCA

Par défaut, une vue est visible de tout utilisateur ayant au moins l’accès Lecteur dans la LCA de la base. L’utilisateur ne verra cependant pas les documents pour lesquels son nom est absent de champs de type Lecteurs et Auteurs lorsque un ou des champs de type Lecteurs sont présents. L’utilisation de champs de type Lecteurs devrait être limitée dans une application : une systématisation peut déboucher sur de mauvaises performances. Le contrôle de l’accès et de l’affichage au niveau de la vue sont préférables au contrôle de l’affichage au niveau document avec les champs Lecteurs. Les solutions mises en place tiennent compte des recommandations suivantes :

– Spécialiser les vues par catégories d’acteurs – pour le confort des utilisateurs – en jouant sur les rôles de la LCA,

– Utiliser l’affichage d’une catégorie de la vue (vue intégrée dans un masque), – Masquer des colonnes selon le rôle de l’utilisateur, – Créer des vues privées ou partagées devenant privées à la première utilisation, – Minimiser le nombre de vues.

Remarque Si un utilisateur n’a pas accès à une vue, il peut toujours en construire une et consulter les documents compris dans la formule de sélection de la vue, à moins que les documents soient protégés par un champ de type Lecteurs. Les vues à accès restreint ne sont donc pas une mesure de protection de la confidentialité des informations. Ce paragraphe aborde le contrôle d’accès à une vue partagée et privée et quelques exemples d’utilisation de cette technique.

Vue partagée Le module Gérer l’accès à l’application/Droits fonctions @ spéciales présente le scénario qui suit : la vue Codes\2. Type de réunion n’est visible que des utilisateurs ayant le rôle [Gestionnaire].

• Afficher les propriétés de la vue



Cliquer sur l’onglet (Sécurité).

• Désélectionner Tout utilisateur ayant au moins l’accès Lecteur

• Sélectionner le rôle

Dans l’application de gestion des tâches, on peut imaginer une vue réservée aux organisateurs – acteurs identifiés par un rôle – qui présente l’ensemble des documents quel que soit leur Statut.

Vue privée Une vue privée ou une vue partagée devenant privée à la première ouverture n’est visible que de son créateur ou de l’utilisateur qui l’a ouverte. La formule de sélection de la vue comprend habituellement le nom de l’utilisateur courant. La vue partagée devenant privée à la première ouverture peut être protégée pour que seule une catégorie d’utilisateurs puisse créer des vues privées à partir de ce modèle.

Ce type de vue est identifié avec une icône spéciale dans la liste des vues de Designer.

Utilisation de la méthode Cette méthode sert principalement à limiter le nombre de vues affichées à un utilisateur ce qui simplifie la navigation dans l’application. Les autorisations d’accès sont liées à l’utilisation de rôles dans la LCA pour délimiter les catégories d’utilisateurs. Les vues qui sont d’accès restreint sont :

– Les vues affichant les listes de codes internes à l’application, – Les vues destinées à la correction d’anomalies d’exploitation comme les conflits de

réplication, – Les vues réservées aux utilisateurs intervenant dans le processus du workflow.

Type de vue Emplacement

Modèle Critères de sélection

Rôle sélectionné



Contrôler le masque utilisé depuis une vue Contrôler le masque utilisé depuis une vue

Une formule dans la vue détermine le nom du masque

D’après l’utilisateur, l’état du document

Le même document peut être visualisé ou modifié par plusieursmasques : attention au contenu de Form après enregistrement

Les masques ont plusieurs pseudonymes

Un pseudonyme pour l’identification dans la formule de masque

Un pseudonyme – le dernier – pour l’enregistrement dans Form

Recommandations

Préférer les sous-masques calculés

Réserver le contrôle de masque dans la vue à l’affichage pourimpression (masque avec SaveOptions = “0”)

Le paragraphe Créer une section d’accès contrôlé montre comment utiliser des sections d’accès contrôlé et des sous-masques pour personnaliser le masque chargé d’afficher un document à l’utilisateur. Le choix du masque peut également être déterminé par une formule au niveau de la vue. Ceci permet d’atteindre des objectifs similaires :

– Choisir le masque d’après l’état du document : en cours de création, existant, test d’un indicateur (par exemple le Statut),

– Choisir le masque d’après l’utilisateur et son rôle (type d’acteur) par rapport au document : le créateur du document, un auteur par délégation,

– Utiliser une mise en page spécifique à l’impression : c’est la raison principale d’utilisation de cette technique actuellement.

Ce paragraphe décrit comment écrire la formule dans la vue et les précautions à prendre pour la codification des pseudonymes de masques.

Formule de masque dans la vue • Cliquer sur l’événement de vue Formule de masque

utilCourant := @Name([CN] ; @UserName) ; estceOrganisateur := @Contains(@UserRoles ; "[Organisateur]") ;org := @Name([CN] ; Organisateur) ; @If (utilCourant = org ; "masTacheOrganisateur" ; @IsNewDoc & estceOrganisateur ; "masTacheOrganisateur" ; @IsNewDoc & !estceOrganisateur ; "masTacheErreur" ; "masTacheAffecte" )



L’application a prévu trois masques : masTacheOrganisateur (masque spécifique aux utilisateurs ayant le rôle [Organisateur]), masTacheAffecte (masque destiné aux autres utilisateurs) et masTacheErreur (pour afficher un message d’erreur).

L’exemple proposé ici se décortique comme suit :

– le prénom et le nom de l’utilisateur courant sont récupérés dans une variable de travail et son rôle (LCA) [Organisateur] sous forme d’un booléen,

– le prénom et le nom de l’organisateur sont récupérés du document tâche dans une variable de travail,

– @If retourne le nom d’un masque à utiliser.

Condition Masque

Le document existe et l’utilisateur courant est l’organisateur identifié dans le document

masTacheOrganisateur

Le document est nouveau et l’utilisateur a le rôle [Organisateur]

masTacheOrganisateur

Le document est nouveau et l’utilisateur n’a pas le rôle [Organisateur]

masTacheErreur

Le document existe et l’utilisateur n’a pas le rôle [Organisateur]

masTacheAffecte

Pseudonymes de masques Lorsqu’un document peut être affiché et modifié par plusieurs masques, il est essentiel que le contenu de l’item Form soit identique : il faut donc que le pseudonyme de tous ces masques soit toujours le même. Le nom de masque retourné par une formule de vue ne peut donc être celui qui est enregistré dans l’item Form. Il faut donc jouer sur le nom du masque à gauche du caractère pipe ( | ) ou jouer sur des pseudonymes multiples.

• Afficher les propriétés du masque

• <Nom> : taper le nom du masque suivi de deux pseudonymes, par exemple Tache Organisateur | masTacheOrganisateur | masTache

• <Affichage> : décocher les deux options Inclure dans le menu et Inclure dans le Générateur de requêtes pour limiter l’usage des masques

Le nom de gauche – Tache Organisateur –, n’est pas utilisé dans une formule. Le premier pseudonyme – masTacheOrganisateur – est utilisé dans une formule de masque de vue. Le second pseudonyme – masTache – est enregistré dans l’item Form et testé dans les formules de sélection de vue.

De la même façon, le masque destiné aux autres utilisateurs aura comme nom : Tache Affecte | masTacheAffecte | masTache

Cette technique est inutilement complexe dans le cas présenté ici : il vaut mieux concevoir un masque avec deux sous-masques incorporés par formule. Si la technique est retenue pour l’impression des documents, ajouter dans le masque d’impression un champ SaveOptions Calculé à l’affichage, caché, de valeur “0” par précaution.




L’archivage a été identifié dans le diagramme d’états-transitions

Etat du document : la transition d’archivage est possible

Acteur : un utilisateur archiviste ou un agent selon que latransition est déclenchée manuellement ou d’après l’âge dudocument

La transition d’archivage consiste

A copier le document dans une basespéciale, par exemple par routage

A le supprimer dans la base d’origine

Base d’archives : il est prévu de conserver les documents

Les documents peuvent être affichés mais non modifiés


Notes offre des méthodes d’archivage standard qui sont parfaitement applicables à des bases de conférences, des kiosques d’informations… toutes bases pour lesquelles la règle d’archivage est simple et peut s’exprimer en une durée de vie applicable à tous les documents de la base. Les bases documentaires gérant des versions de documents, ou les bases de workflow dans lesquelles les documents appartiennent à un processus, demandent des règles plus élaborées qu’il vous appartient de développer. Ce paragraphe examine les règles d’archivage, la création d’une base d’archives et le processus d’archivage proprement dit. L’archivage a été prévu lors de la modélisation du processus et apparaît dans les cas d’utilisation et le diagramme d’états-transitions.

Règles d’archivage L’événement qui déclenche l’archivage peut être :

– Les tâches dont le statut est Abandonnée doivent être archivées dans une base réservée automatiquement dans les 24 heures,

– Les tâches dont le statut est Publiée doivent être copiées dans une base de Publication immédiatement,

– Dans la base de gestion de la qualité, un document décrivant une procédure ISO remplacé par une nouvelle version est archivé par l’acteur archiviste qui procède manuellement au déplacement des documents dans la base d’archives.

La gestion de l’archivage nécessite éventuellement la création d’un nouvel état du document, lorsqu’il reste en attente d’archivage pendant un certain temps. Cet état détermine sa visibilité – limitée – et l’exécution de l’archivage proprement dit.

Base d’archives La base d’archives est munie des fonctions suivantes :

– affichage des documents archivés dans les vues conçues pour la consultation, – affichage des documents avec des masques ne permettant pas de mise à jour.



La base d’archives peut donc être créée à partir de la base d’origine par copie puis par simplification de la structure. La base d’archives étant créée, un document Base Courrier en arrivée associé permettra l’utilisation du routeur pour envoyer les documents dans la base.

Processus d’archivage Le processus d’archivage est implanté comme formule dans un agent planifié, l’événement Clic d’un bouton ou d’une action, l’événement onSubmit (QuerySave) d’un masque… Elle se décompose en trois étapes principales :

– vérification de l’état du document : peut-il être archivé par l’utilisateur courant qui en fait la demande,

– envoi du document dans son intégralité à la base d’archivage, – suppression du document de la base.

Envoi du document La fonction @MailSend (sans paramètres) associée à un champ SendTo contenant le nom de la base d’archives (d’après le document Base Courrier en arrivée) accomplit cette étape. Un indicateur contenant la date et l’heure d’envoi du document est créé.

Suppression du document de la base La fonction @DeleteDocument accomplit cette étape. Elle fonctionnera si l’utilisateur courant ou le signataire de l’agent planifié a le privilège ⌧Supprimer des documents dans la LCA de la base.

La suppression d’un document d’une base devrait être gérée dans les applications de type workflow par des contrôles supplémentaires. Dans l’exemple de workflow de tâches, seul l’organisateur peut supprimer les documents dont il est l’auteur. Il a donc seul ce privilège parmi les utilisateurs. On peut préciser ce droit avec les règles suivantes :

– tant qu’une tâche est En attente – il n’y a pas de personne affectée – alors l’organisateur peut supprimer le document,

– si une tâche est déclarée Abandonnée et si l’indicateur d’envoi du document à la base d’archives est renseigné avec une date/heure, alors l’organisateur ou un agent planifié peuvent supprimer le document.

Une solution courante consiste à écrire ces règles en LotusScript dans l’événement QueryDocumentDelete de la base – qui s’exécute avant que le document soit marqué pour suppression – ou l’événement PostDocumentDelete – qui s’exécute avant que le document soit réellement supprimé.

• Cliquer Autres, puis Ressources de base de documents, puis Script de la base

Les suppressions peuvent aussi être de type soft delete et récupérées par programmation.

Supprimer des documents



Rappel des objectifs Rappel des objectifs

Savoir-faire

Utiliser le routeur pour faire circuler les documents

Utiliser les rôles et les champs Lecteurs et Auteurs pour contrôlerla visibilité et la modification des documents

Gérer les accès à l’intérieur d’un document par section d ’accèscontrôlé

Contrôler l’état d’un document dans le workflow

Utiliser des documents profil

Connaissance

La typologie de workflow et l’analyse d’une application workflow

Domino.workflow

Le workflow consiste pratiquement à faire circuler entre les acteurs d’un processus des documents dématérialisés. Domino/Notes se prête bien à certaines formes de workflow.

Ce chapitre a pour objectif d’apprendre à mettre en œuvre un workflow modélisé avec des outils UML, essentiellement les cas d’utilisation et le diagramme états-transitions. Le lecteur saura également utiliser les fonctions de routage de Domino dans le langage de formules pour notifier les acteurs ou déplacer un document d’une base vers une autre. Les contrôles d’accès aux documents sont approfondis. Le générateur Domino Workflow est présenté rapidement. La sécurité et le routage de documents sont revus et mis en application.

Résumé du chapitre

La typologie du workflow Une application workflow automatise une séquence d’actions, d’activités ou de tâches dans un processus donné : une demande d’achats, le règlement d’un litige, une mise au contentieux, le règlement d’un sinistre… Le workflow comprend également les outils nécessaires pour connaître l’état de chaque instance du processus ainsi que pour gérer le déroulement du processus. Le champ du workflow est donc vaste et les problématiques sont de complexité variable. Une classification est proposée par Setrag Khoshafian et Marek Buckiewicz dans Introduction to Groupware, Workflow and Workgroup Computing (John Wiley & Sons, Inc.) :

– Workflow administratif, – Workflow ad hoc, – Workflow de production.

Lotus propose une classification assez proche prenant en compte les fonctions de partage collaboratif de Notes.



Domino Workflow Domino Workflow est une application Lotus Notes qui supporte le développement de workflows ad hoc et de production : analyse et conception de l’application, exécution, visualisation d’un processus en cours. Domino Workflow se décompose en :

– Architect : la conception du workflow, – Engine : le moteur d’exécution, – Viewer : l’outil d’interrogation et de suivi des processus.

Application de suivi des tâches L’application de suivi de réalisation de tâches qu’il s’agit de réaliser a été présentée dans module Méthodologie élémentaire. C’est un workflow très simple qui parcourt les techniques de programmation utilisées dans ce type d’application en les reliant à une méthode générale d’analyse fondée sur UML.

Diagramme des cas d’utilisation Ces diagrammes présentent l’application du point de vue des utilisateurs.

– Les acteurs qui interagissent avec l’application, personnes et processus externes, souvent représentés par des rôles dans la LCA de la base, ici l’organisateur et l’employé,

– Le domaine couvert par l’application et ses interfaces avec les autres applications vues comme des acteurs,

– Les fonctions attendues, ici attribuer une tâche, exécuter une tâche, contrôler le travail.

Diagramme de classes Deux types de documents sont représentés dans le diagramme de classes : le Compte rendu et la Tâche. Zéro, une ou plusieurs tâches sont reliées au compte rendu et chaque tâche ne dépend que d’un compte rendu (cardinalité).

Les opérations applicables aux tâches – méthodes dans la terminologie OO – sont symbolisées dans la partie inférieur du cadre représentant la classe Tâche. Ce sont Notifier(), Terminer(), Corriger(), Approuver() et Abandonner().

Diagramme d’états-transitions Ce diagramme décrit les états successifs d’une tâche. L’attribut Statut de la classe Tâche prend les valeurs En attente, En cours, Effectuée, Publiée et Abandonnée. L’état initial est symbolisé par un cercle plein au départ et l’état final par deux cercles concentriques.

Chaque rectangle symbolise un état et le texte sur la transition indique l’acteur – ou l’événement – à l’origine de la transition et l’action effectuée.

Le routeur de messagerie Notifier un acteur lorsqu’un travail est en retard, publier un document dans une base s’appuient sur le mécanisme de routage de courrier de Domino. Le routeur de messagerie est la tâche s’exécutant sur le serveur Domino qui achemine les messages depuis la boîte de routage MAIL.BOX vers leurs destinataires. Le routeur consulte l’annuaire Domino du domaine – names.nsf – pour obtenir des informations sur les destinataires : personnes et bases Courrier en arrivée.

Envoyer une notification à un utilisateur Une notification est envoyée à un utilisateur dans sa base Courrier :

– Lorsqu’une tâche urgente le sollicite, – Lorsqu’une tâche est en retard.



Une notification est générée avec la fonction @MailSend codée avec des paramètres. [IncludeDocLink] permet de créer un LienDoc avec le document faisant l’objet de la notification.

Envoyer un document L’envoi d’un document en entier se fait avec @MailSend sans paramètres. Il peut également être programmé avec l’une des deux techniques suivantes :

– l’affichage d’un dialogue à l’enregistrement du document par une propriété du masque,

– l’utilisation d’un champ MailOptions dans le masque qui laisse choisir l’utilisateur ou force l’envoi du document – ou l’interdit –.

Dans les deux cas, le champ SendTo détermine le nom du ou des destinataires.

Utiliser les rôles Le rôle correspond à un acteur identifié dans les diagrammes de cas d’utilisation. L’acteur a un rôle dans l’application qui est souvent traduit par un rôle dans la LCA – Liste de contrôle d’accès de la base –. Le rôle dans la LCA correspond normalement à un type d’acteurs accomplissant des fonctions données dans le workflow : initialiser un processus ou intervenir dans un processus en dehors du simple contexte du document.

Modifier un document sous condition Les utilisateurs qui ont besoin de créer et/ou de modifier des documents ont un droit d’accès Auteur dans la LCA de la base. Le droit d’accès Editeur – qui permet de créer des documents et de modifier n’importe quel document – est trop élevé et ne devrait être donné qu’à un groupe restreint d’utilisateurs gérant la base.

Déterminer la visibilité d’un document Les utilisateurs qui ont besoin de lire des documents ont ont un droit d’accès Lecteur au minimum dans la LCA de la base. Le droit générique de lecture de n’importe quel document peut être restreint en utilisant des vues réservées et des formules de sélection comme cela a été décrit dans le paragraphe Utiliser les rôles. Une autre technique consiste à utiliser des champs de type Lecteurs listant les personnes, groupes et rôles pouvant lire le document quelle que soit la vue dans laquelle il apparaît.

Créer une section d’accès contrôlé Les utilisateurs qui ont besoin de créer et/ou de modifier des documents ont un droit d’accès Auteur dans la LCA de la base et sont présents dans des champs Auteurs des documents. A l’intérieur d’un document, la section d’accès contrôlé détermine qui peut modifier telle ou telle partie du document. Une section d’accès contrôlé peut être remplacée par deux sous-masques insérés par formule : un sous-masque permettant de modifier les champs et le second ne faisant que de l’affichage. La formule d’insertion des sous-masques est logiquement la même que la formule qui détermine les éditeurs d’une section.

Contrôler l’état d’un document Le diagramme d’états-transitions met en évidence les états de gestion d’un document : ceux qui ont un sens pour les utilisateurs. Le passage d’un état vers un ou d’autres états se fait par des transitions – sortie d’un état et entrée dans le suivant – qui correspondent à des actions de l’utilisateur ou à des actions déclenchées automatiquement en fonction du temps le plus souvent.



L’état est un attribut de la classe entité et correspond à un item spécifique du document – par exemple Statut – dans Domino. Lorsque le document est dans un état donné, deux types de transitions et des activités sont habituellement identifiés :

– Transitions de sortie figurées sur le diagramme d’états-transitions par le texte attaché à la flèche matérialisant la transition.

– Transitions internes correspondant à des traitements qui ne modifient pas l’état du document et documentées dans le diagramme d’états-transitions.

– Activité correspondant à des traitements récurrents – notés Do dans un diagramme UML – qui ne peuvent se rattacher qu’à l’état et qui cessent quand le document sort de l’état.

Contrôler l’accès à une vue Par défaut, une vue est visible de tout utilisateur ayant au moins l’accès Lecteur dans la LCA de la base. L’utilisateur ne verra cependant pas les documents pour lesquels son nom est absent de champs de type Lecteurs et Auteurs lorsque un ou des champs de type Lecteurs sont présents. Les solutions mises en place tiennent compte des recommandations suivantes :

– Spécialiser les vues par catégories d’acteurs – pour le confort des utilisateurs – en jouant sur les rôles de la LCA,

– Utiliser l’affichage d’une catégorie de la vue (vue intégrée dans un masque), – Masquer des colonnes selon le rôle de l’utilisateur, – Créer des vues privées ou partagées devenant privées à la première utilisation, – Minimiser le nombre de vues.

Contrôler le masque utilisé dans une vue Le choix du masque utilisé pour visualiser ou modifier un document peut être déterminé par une formule au niveau de la vue. Ceci permet de :

– Choisir le masque d’après l’état du document : en cours de création, existant, test d’un indicateur (par exemple le Statut).

– Choisir le masque d’après l’utilisateur et son rôle (fonction) par rapport au document : le créateur du document, un auteur par délégation.

– Créer un masque ne servant qu’à l’affichage et/ou l’impression du document.

Archivage de documents Notes offre des méthodes d’archivage standard qui sont parfaitement applicables à des bases de conférences, des kiosques d’informations… toutes bases pour lesquelles la règle d’archivage est simple et peut s’exprimer en une durée de vie applicable à tous les documents de la base. L’archivage a été prévu lors de la modélisation du processus et apparaît dans les cas d’utilisation et le diagramme d’états-transitions avec des règles déterminées.

Points essentiels La modélisation du workflow permet d’identifier les états d’un document, les transitions d’un état vers un autre, le rôle des acteurs – utilisateurs, processus, mécanismes externes – et du temps dans le déclenchement des transformations. La recommandation est d’utiliser un style de programmation regroupant autant que possible les règles du workflow dans un nombre limité d’événements. Cette approche est facilitée en LotusScript avec lequel la création d’objets métier fait correspondre la modélisation et la programmation.



Atelier 11

Durée :

• 4 heures 45 minutes

Objectifs :

• Ecrire un workflow de gestion de tâches

• Contrôler les accès de deuxacteurs

• Envoyer des notifications

Atelier 11

Exercice 1 : Créer le masque Tâche et une notification 45 mn Le workflow de tâches est développé dans la base de suivi de projets. Un seul document est pris en compte dans le workflow de tâches : il décrit une tâche à accomplir et doit recevoir le résultat du travail sous forme d’une ou plusieurs pièces attachées : fichier de traitement de texte, présentation, feuille de calcul. L’organisateur (de la réunion) crée un document à chaque fois qu’il y a une tâche à accomplir définie au cours de la réunion et affecte un employé à cette tâche. Un mécanisme de notification signale à l’employé qu’il a un travail à accomplir.

Etapes L’exercice se divise en trois étapes :

– La création du masque, – La création d’une vue permettant de visualiser les tâches, – La création du système de notification.

• Modifiez les propriétés de la base pour ne pas afficher l’agencement de cadre et

sélectionnez Afficher la dernière vue utilisée

Les vues créées seront intégrées dans le plan de navigation quand elles seront au point.

• Créez le masque Tâche avec le pseudonyme masTache dans la base de Suivi de projets

• Créez les champs selon le tableau

Champ Propriétés

Organisateur Type Noms, Modifiable, Nom de l’utilisateur courant par défaut, Obligatoire.



Champ Propriétés

NomProjet Type Liste de dialogue ou Liste déroulante. Valeurs prises de la vue vueNomProjet, Obligatoire.

Categories Type Liste de dialogue ou Liste déroulante. Valeurs identiques à celles du champ Categories utilisé dans les documents Ordre du jour et Compte rendu. Obligatoire.

TitreTache Type Texte, obligatoire.

Affecte Type Noms, valeur récupérée de l’annuaire Domino du domaine.

DateFinPrevue Type Date/Heure, afficher la date seulement.

DatePublication Type Date/Heure, afficher la date seulement.

DateFinReelle Type Date/Heure, afficher la date seulement.

Statut Type Liste de dialogue ou Liste déroulante. Valeurs (synonyme) : En attente (EA), En cours (EC), Effectuée (EF), Publiée (PU), Abandonnée (AB). Ce champ est provisoirement modifiable.

Body Utiliser le champ partagé : type Texte riche.

• Créez la vue Taches\1. Par Organisateur catégorisée par Organisateur qui affiche uniquement les tâches

• Créez les colonnes

Colonne Propriétés

1 Nom propre de l’organisateur, catégorisée

2 Nom du projet, catégorisée



Colonne Propriétés

3 Date de fin prévue, classée par ordre croissant

4 Titre de la tâche et nom de la personne entre parenthèses si renseigné

• Créez dans le masque Tâche un bouton d’action (Notifier) qui envoie à la personne affectée un message reprenant le titre de la tâche et un LienDoc vers le document de tâche. S’il n’y a pas de personne affectée, envoyez un dialogue indiquant que l’envoi n’a pas été effectué

• Créez un deuxième bouton (Envoyer) qui envoie la totalité du document à la personne affectée

• Est-ce que le document apparaît dans la corbeille Arrivée de la base Courrier du destinataire ? Est-ce que le document peut être consulté ? Pourquoi ?

Procédures

Reportez-vous aux pages 11-8 à 11-11.

Exercice 2 : Rôles 20 mn La création d’une tâche est du ressort de l’organisateur qui initialise le processus. Par ailleurs, il est nécessaire de créer des vues spécifiques aux organisateurs et de les séparer des vues utilisées par les personnes affectées.

Etapes

• Créez un rôle [Organisateur] dans la LCA de la base

• Créez la vue Taches\2. Par Affectation catégorisée par Personne affectée qui affiche uniquement les tâches

• Réservez la vue Taches\1. Par Organisateur aux seules personnes de rôle [Organisateur]

• Créez une vue Taches\0. Par organisateur(privée) de type Partagé, devenant privé à la 1ère ouverture sur le modèle de Taches\1. Par Organisateur. Cette vue est réservée aux utilisateurs ayant le rôle [Organisateur] et doit afficher les seules tâches gérées par l’utilisateur courant

Procédures




Exercice 3 : Champs Auteurs et Lecteurs 35 mn La personne affectée doit pouvoir modifier le document de tâche. Le traitement de détermination de l’auteur se fait automatiquement à l’enregistrement du document. Lorsqu’un document de tâche est en cours de rédaction, il faut pouvoir en limiter la visibilité.

Etapes

• Modifiez le masque Tâche


Pseudonyme EA EC EF PU AB

Auteurs [Admin] Organisateur

[Admin] Organisateur

Affecte

[Admin] Organisateur

[Admin]

[Admin]

Les règles récapitulées dans le tableau indiquent, par état du document, qui peut le modifier.

• Créez un champ AuteursDoc qui permette à la personne affectée par l’organisateur à la réalisation de la tâche de modifier le document. La valeur de ce champ est calculée à l’enregistrement du document : événement onSubmit (QuerySave)

• Vérifiez le fonctionnement de AuteursDoc en créant un document avec un ID (l’organisateur) et en le modifiant avec un autre ID (la personne affectée)

Le test doit s’effectuer avec la base sur serveur ou bien avec une base locale et une LCA cohérente.

• Créez un champ LecteursDoc de type Lecteurs pour enregistrer les lecteurs du document. La valeur de ce champ sera toujours calculée en dehors de ses propres événements

• Créez un bouton d’action (Marquer privé/Marquer public) avec les caractéristiques suivantes : – Au premier clic, il rend le document visible uniquement de l’organisateur et de la personne affectée en utilisant un champ LecteursDoc – Au clic suivant, il rend le document visible de tous – Son libellé change selon l’action qu’il va effectuer

Pour éviter les situations de blocage, un rôle Admin est prévu pour déverrouiller toutes les situations : si un organisateur remplace son nom par celui d’une autre personne et qu’il marque le document privé, il ne verra plus le document qu’il a créé.

• Créez le rôle [Admin] dans la LCA de la base

• Créez un champ AuteursAdmin qui contienne uniquement le rôle [Admin] et tel que l’utilisateur en possession de ce rôle puisse toujours voir et modifier le document

• Vérifiez le fonctionnement de LecteursDoc avec des utilisateurs présents ou non dans ce champ

Procédures




Exercice 4 : Section d’accès contrôlé 30 mn

Etapes

La personne affectée à une tâche ne doit pas avoir accès en modification aux champs de la responsabilité de l’organisateur et réciproquement. Une première solution passe par la création de sections d’accès contrôlé dans un masque. Une autre solution consiste à créer des sous-masques dédiés à chacun des deux acteurs. Le champ Statut est accessible par les deux acteurs puisqu’ils le font évoluer par leurs actions. Il ne sera pas protégé pour le moment et la bonne volonté de chacun devrait suffire en attendant une solution prochaine.

• Faites une copie du masque Tâche de façon à en avoir une sauvegarde

• Organisez le masque de telle façon que les données modifiables par l’organisateur – Organisateur, NomProjet, Categories, TitreTache, Affecte, DateFinPrevue, DatePublication – soient séparées de celles modifiables par la personne affectée – Body et DateFinReelle –. Vous devez tenir compte du fait qu’un tableau ne peut être inclus partiellement dans une section

• Créez une section d’accès contrôlé Organisateur modifiable par l’organisateur et par une personne ayant le rôle [Admin] qui sert de dépannage. La règle ne peut être modifiée et doit toujours s’appliquer

Pour faciliter le développement et la mise au point, vous pouvez créer un champ calculé à l’affichage pour chaque section qui retourne la liste des éditeurs de la section. Ce champ est repris dans la formule d’accès de la section d’accès contrôlé, elle-même du type calculé à l’affichage.

• Créez une section d’accès contrôlé Affecte modifiable par la personne affectée et par une personne ayant le rôle [Admin] qui sert de dépannage. La règle ne peut être modifiée et doit toujours s’appliquer

Remarque Le champ Statut est en dehors de toute section. • Effectuez un test et constatez également que même si vous êtes Gestionnaire dans

la LCA de la base, vous ne pourrez pas accéder en modification au contenu d’une section d’accès contrôlé si vous ne faites pas partie des éditeurs de la section

• Double-cliquez sur l’en-tête d’une section pour voir les éditeurs de la section

• Constatez qu’en vous donnant le rôle [Admin], vous avez accès à toutes les sections d’accès contrôlé dans votre base

• Modifiez le nom du masque en Tâche (sections) | masTacheSection pour ne pas perdre votre travail et de façon à ce qu’il n’interfère pas avec le développement qui suit

Procédures

Reportez-vous aux pages 11-18 à 11-19, 9-16 à 9-18.



Exercice 5 : Alternative : sous-masque 30 mn

Etapes

La solution consistant à créer des sous-masques dédiés à chacun des deux acteurs plutôt que les sections d’accès contrôlé est développée maintenant.

• Repartez de la copie du masque Tâche que vous avez faite en début d’exercice précédent, avant l’incorporation des sections d’accès contrôlé

• Créez le sous-masque smTacheOrganisateur qui comprend tous les champs du masque Tâche : opérez par copier/coller. Reportez-vous au module Fonctions avancées du masque/Sous-masque

• Transformez les champs qui suivent pour qu’ils ne soient plus modifiables mais calculés à l’affichage : Body (Calculé), DateFinReelle. Reportez-vous au module

Programmer avec le langage de formule/Masquer un paragraphe

• Créez le sous-masque smTacheAffecte qui comprend tous les champs du masque Tâche : opérez par copier/coller

• Transformez les champs qui suivent pour qu’ils ne soient plus modifiables mais calculés à l’affichage : Organisateur, NomProjet, Categories, TitreTache, Affecte, DateFinPrevue, DatePublication

• Créez le sous-masque smTacheAffiche à partir du sous-masque smTacheAffecte : opérez par copier/coller

• Transformez les champs modifiables restants en champs calculés à l’affichage : Body (Calculé), DateFinReelle

• Modifiez le masque Tâche pour que l’insertion d’un sous-masque tienne compte de l’état du document et de l’utilisateur courant

Situation Sous-masque

Nouveau document smTacheOrganisateur

Document existant, l’utilisateur est l’organisateur smTacheOrganisateur

Document existant, l’utilisateur est la personne affectée

smTacheAffecte

Document existant, l’utilisateur n’est ni l’organisateur, ni la personne affectée

smTacheAffiche

• Vérifiez le résultat

Remarque La technique du sous-masque permet une plus grande liberté de mise en page que les sections d’accès contrôlé. Par ailleurs, dans certaines versions de Designer, les sections d’accès contrôlé ne fonctionnent pas très bien.

Constatez la différence avec le champ Body : s’il y a une pièce attachée, les deux techniques sont identiques. S’il y a des objets incorporés, des images, le résultat peut être différent à l’affichage. • Décidez de conserver l’une des deux solutions : le masque qui appelle deux sous-

masques ou le masque avec des sections. Le masque que vous conservez devra avoir comme pseudonyme masTache et être le seul à porter ce pseudonyme. Si vous conservez la première solution, vous devrez porter des modifications dans le masque et les deux sous-masques dans l’atelier qui suit



Procédures

Reportez-vous aux pages 11-18 à 11-19, 9-16 à 9-18.

Exercice 6 : Etat d’un document 45 mn

Etapes

L’état du document est géré manuellement dans le champ Statut. Le masque Tâche va être modifié pour prendre en compte le fait que deux acteurs peuvent modifier le Statut.

Les directives données ici ne correspondent pas exactement aux exemples donnés dans le module dans le but de créer des variantes pédagogiques. La solution proposée est loin d’être la seule.

Statut du document Le Statut modifiable par acteur : organisateur et employé affecté. Un champ modifiable spécifique à chacun est créé, respectivement orgStatut et empStatut. Le statut saisi par un acteur est reporté dans le champ Statut qui devient calculé à la création (donc, non modifiable directement).

La liste des états proposés à l’utilisateur devra dépendre de l’état actuel du document.

Acteur Statut courant Nouveaux statuts possibles

EA (En attente) En cours (EC)

1. EA (En attente) 2. En cours (EC) 5. Abandonnée (AB).

Effectuée (EF) 4. Publiée (PU) 5. Abandonnée (AB) 2. En cours (EC)

Organisateur

Abandonnée (A) Publiée (PU)

-vide-

Employé affecté En cours (EC) 2. En cours (EC) 3. Effectuée (EF)

Si le Statut est “EC”, la DateFinReelle ne peut être renseignée et elle est vidée.

La difficulté de l’atelier consiste :

– à calculer la liste des valeurs proposées à l’utilisateur courant en fonction de son rôle et de l’état du document

– à ne montrer les boutons (Modifier) et (Enregistrer) que lorsqu’ils sont utilisables – à gérer par formule les listes de valeurs et les pseudonymes du Statut

Affichage du statut Les valeurs possibles du statut et les pseudonymes associés sont créés sous forme de liste dans un champ calculé à l’affichage. Le texte ne servira qu’à l’affichage et les pseudonymes seront testés dans les formules. Il faut pouvoir associer le pseudonyme à un texte.



• Créez le champ listeStatut, de type Calculé à l’affichage et caché. La valeur est la

liste des textes et des pseudonymes "En attente | EA" : "En cours | EC" : "Effectuée | EF" : "Publiée | PU" : "Abandonnée | AB"

Le caractère pipe ( | ) sépare texte et pseudonyme exactement comme dans le dialogue de saisie des valeurs du champ Statut. Le caractère deux-points ( : ) sépare les éléments d’une liste.

• Modifiez le champ Statut pour que la liste de valeurs proposées vienne du champ listeStatut (c’est une formule très simple)

• Vérifiez que l’affichage des valeurs proposées à l’utilisateur sont inchangées et que le pseudonyme est bien enregistré dans le document

• Transformez le champ Statut en calculé à la création, l’événement valeur contenant la valeur initiale, soit “EA”

Le contenu de Statut sera modifié depuis l’événement onSubmit. Pour le moment, il est clair que la valeur “EA” – enregistrée dans le document – doit être affichée “En attente” pour plus de clarté.

• Créez un champ Statut_D, calculé à l’affichage

L’événement valeur du champ contient une formule qui teste le contenu de Statut et retourne le libellé correspondant qui se trouve dans le champ listeStatut. Pour atteindre ce résultat, les éléments suivants sont utilisés :

– tests de Statut (pseudonymes) – accès à un poste de listeStatut par la notation listeStatut[1], listeStatut[2], etc. – accès au libellé par la fonction @Left en utilisant le caractère pipe ( | ) comme

séparateur • Testez le résultat à l’affichage en créant un nouveau document

Modification de Statut L’organisateur et la personne affectée vont chacun saisir le statut dans des champs séparés à l’intérieur de leur section. Nous allons supposer dans un premier temps que les utilisateurs sont bien élevés et qu’ils ne choisiront que les valeurs licites. Le calcul des listes de valeurs licites sera effectué ensuite.

• Créez les deux champs modifiables orgStatut et empStatut dans les sections Manager et Affecte. La liste complète des valeurs de Statut est proposée à l’utilisateur

• Mettez à jour Statut dans l’événement onSubmit (QuerySave) du masque



L’événement contient déjà le calcul des champs Auteurs. Comme ce calcul s’appuie sur Statut, il faut que le statut soit calculé avant. La règle de calcul de Statut depuis les champs de saisie est très simple :

– Si le champ orgStatut est renseigné, alors Statut prend sa valeur – Si le champ affStatut est renseigné, alors Statut prend sa valeur – Sinon, rien ne se passe Le postulat est que soit orgStatut, soit affStatut est renseigné, mais pas les deux. Ceci est normalement assuré par l’accès aux sections.

• Vérifiez le résultat : la valeur de Statut et le libellé associé – Saisie d’une tâche – Modification du statut – En cours – par l’organisateur – Modification du Statut – Effectuée – par l’employé affecté – Modification du Statut – Publiée – par l’organisateur

Calcul des valeurs possibles de Statut La liste des valeurs possibles est maintenant calculée pour que les utilisateurs ne voient que les valeurs possibles. Une solution consiste à calculer ces listes dans des champs calculés à l’affichage, puis à utiliser le nom de la liste dans la formule du champ modifiable.

Champ de saisie Valeur actuelle de Statut Valeurs possibles champ de saisie

EA (En attente) En cours (EC)

1. EA (En attente) 2. En cours (EC) 5. Abandonnée (AB).

Effectuée (EF) 4. Publiée (PU) 5. Abandonnée (AB) 2. En cours (EC)

orgStatut

Abandonnée (A) Publiée (PU)

-vide-

-vide- -vide- empStatut

En cours (EC) 2. En cours (EC) 3. Effectuée (EF)

• Créez deux champs calculés à l’affichage listeOrgStatut et listeAffStatut

L’événement valeur de chacune de ces listes suit la logique exposée dans le tableau. La programmation requise est du style :

– Condition : Statut = "EA" : "EC" – Action : FIELD listeOrgStatut :=

listeStatut[1]:listeStatut[2]:listeStatut[5]; • Masquez les champs de saisie orgStatut et affStatut lorsque les listes

correspondantes sont vides

• Testez en utilisant le tableau ci-dessus

Remarque Dans le scénario, l’utilisateur choisit un Statut, ce qui équivaut à confondre le nom d’une action avec l’état résultant pour le document. C’est une entorse aux principes énoncés précédemment. Elle est voulue pour se concentrer ici uniquement sur les aspects techniques d’implantation.



Lorsque l’utilisateur – organisateur, employé affecté – choisit un état suivant pour lequel il n’est plus auteur, l’enregistrement du document fonctionne une fois mais pas deux. Un dialogue s’affiche à la seconde tentative d’enregistrement.

C’est évidemment perturbant pour l’utilisateur qui n’est pas sûr de l’état du document enregistré. Une solution est proposée dans l’atelier qui suit.

Procédures


Exercice 7 : Notification, masquage de boutons, agent 45 mn

Etapes

Des fonctions supplémentaires sont implantées :

– Notifier l’employé affecté lorsque la tâche arrive à l’état En cours, depuis En attente ou depuis Effectuée. Un bouton est proposé à l’organisateur, ou bien l’opération se fait automatiquement à l’enregistrement du document

– Masquer les boutons (Modifier), (Enregistrer), (Enregistrer et Quitter), (Marquer Public/Privé) lorsque l’utilisateur n’est pas Auteur du document

– Envoyer un message à l’utilisateur lorsque le document a été enregistré et lui proposer de fermer la fenêtre pour éviter les messages perturbateurs lorsque l’utilisateur n’est plus auteur du document

– Développer un agent planifié qui calcule le nombre de jours de retard pour l’affichage dans les vues

Notification • Créez un champ notifAffecte qui enregistre la date et heure d’envoi de la

notification

• Modifiez le bouton (Notifier) pour qu’il ne s’affiche pas si le message a déjà été envoyé

• Modifiez les règles de onSubmit pour que si le statut repasse à En cours, le bouton s’affiche à nouveau

Masquage de boutons Plusieurs boutons doivent être masqués avec la même formule. Pour éviter de dupliquer la formule, une solution possible est de créer un champ calculé à l’affichage, numérique, qui retourne la valeur 1 ou 0 (zéro) selon qu’il faut afficher un bouton ou non.

• Créez le champ SHB_ModEnr, numérique et calculé à l’affichage

• Utilisez ce champ comme un booléen dans une formule de masquage !SHB_ModEnr



Confirmation d’enregistrement Lorsque l’utilisateur enregistre un document, une confirmation lui est envoyée s’il n’est plus auteur avec proposition de fermeture de la fenêtre. Ceci peut être codé par formule dans l’événement PostSave du masque.

• Testez si l’utilisateur courant fait partie des Auteurs du document

• Envoyez le message de confirmation, d’explication et de demande de fermeture de la fenêtre

Agent planifié • Créez un agent planifié – une fois par jour – qui détecte les tâches en retard selon la

règle – Si la date de fin réelle n’est pas renseignée, la date prévue est comparée à la date du jour – Si la date de fin réelle est renseignée et si le retard n’a pas été calculé, la date de fin réelle est comparée à la date de fin prévue

• L’agent enregistre dans un item enRetard le nombre de jours de retard

Note : cet item n’apparaît pas dans le masque Tâche, ce qui n’empêche pas son utilisation dans les vues.

• Faites apparaître le nombre de jours de retard dans les vues Taches\1. Par Organisateur et Taches\2. Par Affectation

Procédures

Reportez-vous aux modules 10 et 6.

Exercice 8 : Archivage et publication d’un document 35 mn

Etapes

Un agent d’archivage planifié déplace les documents à l’état Abandonnée dans une base d’archivage. Lorsque le document est à l’état Publiée, il est copié dans une base de publication. L’archivage et la publication utilisent le routeur de messagerie. Le nom de la base d’archive et celui de la base de publication doivent être enregistrés dans le profil de la base de suivi de projets.

Base d’archive • Créez une base Archives sur le serveur par copie de la base actuelle

• Créez une vue affichant tous les documents de la base catégorisés par pseudonymes de masques et affichant le titre de la tâche, et la date et l’heure de dernière modification

• Mettez l’accès par défaut de cette base à Lecteurs : les managers et les personnes ayant rédigé les documents ne peuvent pas les modifier

• Créez un document Base Courrier en arrivée pour cette base

• Vérifiez qu’un document envoyé à cette base est bien distribué

• Modifiez le profil de la base actuelle pour que le nom de la base archive y soit enregistré



• Créez l’agent planifié archiveTache qui envoie les documents tâches à l’état Abandonnée vers la base d’archives et supprime le document de la base de Suivi de projets

Remarque Il faut que l’agent soit signé par un utilisateur ayant le droit de supprimer les documents dans la base Suivi de projets.

Base de publication • Créez une base Publications sur le serveur par copie de la base actuelle

• Créez une vue listant les tâches par Projet et Titre

• Copiez le masque Tâche de la base Suivi dans la base Publications

• Mettez l’accès par défaut de cette base à Lecteurs : les managers et les personnes ayant rédigé les documents ne peuvent pas les modifier

• Créez un document Base Courrier en arrivée pour cette base

• Vérifiez qu’un document envoyé à cette base est bien distribué

• Modifiez le profil de la base actuelle pour que le nom de la base Publications y soit enregistré

• Lorsque l’organisateur passe le Statut à l’état Publiée, le document est copié vers la base Publications une seule fois et la date de publication est renseignée

Procédures

Reportez-vous aux modules 10 et 6.

Documents

01 Designer V60 AP - Accueil - Librairie Eyrolles · l’ouvrage Introduction to Groupware, ... L’attribut Statut de la classe Tâche prend les valeurs En attente, En cours, Effectuée,