Page 1 sur 1
Blocage document en mise à jour

Publié:
23 Jan 2010 à 15:40
par chollaender
bonjour j'ai une base de données avec une mise à jour par 3 entités. Je souhaite bloquer la mise à jour du document par son auteur initial dès que le document est passé en phase 2 ( une autre entité doit traiter ) . L'auteur ne doit plus pouvoir modifier ou rattacher des pièces jointes .
comment faire .

Publié:
25 Jan 2010 à 08:13
par Michael DELIQUE
salut
tu veux faire un workflow, ilf aut passer par les champs auteur/lecteur

Publié:
25 Jan 2010 à 17:03
par oguruma
identifier les rôles de chaque acteur
faire un schéma de circulation des documents ainsi il sera plus facile d'attribuer les rôles à chaque acteur
déclarer ces rôles dans la lca - cela permettra aussi d'identifier les auteurs et les lecteurs
ne pas oublier l'administrateur fonctionnel de la base à qui on pourra aussi lui attribuer un rôle de Gestionnaire afin qu'il ait toute autorité sur l'application et les documents
les masques comporteront des champs de type lecteur et auteur
ne pas oublier de mettre l'administrateur domino dans le champ lecteur
de préférence on utilisera des rôles pour ces champs et ceux-ci seront valorisés par formules et en général ils sont cachés (en tête du masque)
on identifier les actions communes de manière à en faire des actions partagées - si certaines apparaissent en bloc on les regroupera dans un sous masque
le masque principal fera appel à un ou plusieurs sous masque pour l'affichage des boutons - ces sous masques seront calculés
le masque fera aussi apparaitre des sous masques permettant soit de lire soit de modifier les données - l'affichage de ceux-ci sera évalué en fonction des rôles connus de l'utilisateur (voir la fonction @userroles) - ensuite c'est une belle formule qui affichera le ou les sous masques (lecture/écriture) en fonction du contexte de l'application
ce contexte pourra être déterminé via un statut - il faudra dans ce cas bien identifier ces statuts et les codifier (code+libellé)
prévoir également un sous masque qui hébergera un champ historique des actions effectuées par chaque acteur - on a en général date heure - utilisateur - action et détail de l'action
cet historique est important en cas de litige sur le document...
le pilotage du wkf pourra être géré soit par formule ou par ls (pour ma part je préfère le ls qui offre plus de possibilités)
si possible le ls sera codifié dans une biblio de script et le script ne concernera que le bouton ou quelques bouton - faire l'appel à cette biblio au niveau bouton et non au niveau document afin de pas surcharger inutilement le masque
voici un petit résumé d'une methodo de développement qui rend bien des services quand on doit maintenir l'application ou quand un développeur tierce prend la suite des évolutions