Process en 3 phases

Bonjour, pourquoi ne pas associer à chaque formulaire soumis 2 booléens spécifiant si le superviseur a validé le formulaire et si le manager a validé le formulaire?

Par ailleurs, comment se passe l'affectation du formulaire à tel superviseur et tel manager?*

cordialement

Antho

Merci d'avoir répondu.
Aucune idée...C'est pour cela que je demande à etre orienté vers une approche methodologique. J'ai le tableau de bord, je suis entrain de suivre un cours sur l'affectation des roles et permissions aux utilisateurs, pas difficile quand on a le tutoriel...Mais ce qui me tracasse, c'est la passation du formulaire d'un utilisateur à un autre jusqu'à la fin du process.(c'est à dire que l'utilisateur doit trouver le formulaire reçu dans son espace membre, cliquer sur , l'afficher et valider .

Voici ce que je propose :
1/ Créer les 3 niveaux pour les utilisateurs en BDD dans une table "role" (dans la tables users, tu ajoute un champ role_id pour les lier)
2/ dans le controller du formulaire (si tu es en MVC, sinon c'est pareil de toute façon :) :
Tu crées les 3 fonctions de validation indépendamment :

• function sendFormToSupervisor()
  // La fonction gère la validation, l'envoi du formulaire au superviseur et la notification
• Function sendToManager()
  // la fonction gère la validation, l'envoi du formulaire au manager et la notification
• Function formConfirmation()
  // la fonction gère la validation, et la confirmation du formulaire

Lorsque qu'un utilisateur envoie un formulaire, selon son rôle il appelle telle ou telle fonction.

Pour les notification, il s'agit d'un message à afficher, voilà comment je procèderai :
1/ Je crée une table notification avec comme champs : id, fromuser_id(int), touser_id(int), message (varchar)
2/ A l'intérieur de chaque fonction énumérée ci dessus, à chaque envoi de formulaire validé, j'ajoute une entrée dans cette table avec le message de notification.
3/ J'ajoute un champs "countnotifications" dans la table user

4/ Dans la vue je peux afficher le nombre de notifications et les messages associés, par contre il faut les destroy quand elles sont lues, ou ouvertes.

Voilà un 1er jet sur une organisation possible, à faire évoluer bien entendu.

Tres bien. Voilà ce qu'on appelle un coup de pouce.
Mainant, @validation, ce seront 2 tables(T1->validation/T2->archiveInstance.
PROCESS Accept-> P1-insert into archiveInstance AND delete from validation
PROCESS Rejet-> P2-delete from validation

c logique ce que je viens de dire?...Merci Bkp pour votre intervention.