search

libertempo / web

Application web de gestion des congés en ligne
GNU General Public License v2.0
67 stars 63 forks source link

Affectation du responsable : Gestion des groupes #219

Closed wouldsmina closed 6 years ago

wouldsmina commented 8 years ago

L'affectation d'un responsable se fait, actuellement, à partir du formulaire de création/modification d'un utilisateur ET dans la gestion des groupes (si elle est activée).

Cela génère quelques fois des problèmes pour le traitement des demandes mais surtout pour la gestion des droits d'un responsable avec ces collaborateurs (cf. #218).

Nous envisageons donc de retirer l'affectation d'un responsable depuis le formulaire de création d'un utilisateur pour privilégier l'usage des groupes. Cela implique que la "gestion des groupes" ne sera plus optionnelle.

Nous devrons aussi nous pencher sur l'affectation d'un utilisateur à plusieurs groupes (donc avec plusieurs responsables). De mon point de vu, cela ne devrait pas être possible (un employé ne peut pas être dans 2 services en même temps)...

prytoegrian commented 8 years ago

+1, il y a une grande complexité dans les groupes. Trop grande en fait. Les rendre obligatoires, en plus de nous faciliter le travail, est plus compréhensible pour les utilisateurs finaux : « Responsable X gère les groupe Techniciens et Commerciaux, qui contiennent Employé1, Employé 2, etc », en lieu et place de : « ce qui a été dit précédemment ET / OU la relation binomiale entre un employé et un responsable » (qui n'est pas très lisible, vu qu'on doit partir de l'employé).

Quant au type de relation, je militerais pour une relation :

J'ai dans l'idée que de tels groupes vont nous permettre de poser des règles métiers différentes et j'ai du mal à imaginer un employé qui subira deux contraintes métiers différentes. Nous devrions alors vérifier les collisions entres les diverses règles.

Shadok commented 8 years ago

Pour commencer, il faut savoir que je ne parle que de la page "Responsable" dans le cas d'un utilisateur qui est "Responsable, RH, voit tout".

Cet utilisateur voit donc tous les utilisateurs dont il est directement responsable, et les utilisateurs dont il est N+2 (responsable de leur responsable). Et c'est bien ça qui pose problème, on ne devrait voir que les N-1 et pas les N-2.

Lorsque l'on veut visualiser la fiche d'un N-2, cela nous ramène sur la page de login (sans faire de vraie déconnexion).

prytoegrian commented 8 years ago

@Shadok t'as pas répondu au sujet là :p

Pour ce qui est des groupes à double validation, ça aurait du sens de faire en sorte que le second validateur soit forcément un « Haut Responsable » (et donc en premier validateur, obligatoirement un Responsable) ?

wouldsmina commented 8 years ago

pas sur de bien comprendre la question, mais un haut responsable a aussi des collaborateurs direct, donc en validation simple, ou double mais dans ce cas c'est un autre responsable qui est haut responsable du groupe (pas sur de bien être clair dans ma réponse non plus en fait).

prytoegrian commented 8 years ago

Si si, c'est clair. Tu as répondu à la seconde question. La première était : il me semble qu'actuellement n'importe quel responsable (simple, ou HR) peut être second validateur, est-ce-que ce serait intéressant en terme métier d'être encore plus contraignant, à savoir que le second validateur doit forcément être un HR, et non plus un simple responsable ?

wouldsmina commented 8 years ago

Alors HR = haut responsable soit le grand responsable comme defini dans LT, le RH c'est autre chose. On est d'accord?

Non, il faut être grand responsable d'un groupe en double validation pour traiter les demande de second niveau.

Shadok commented 8 years ago

Sinon, pour la question, il faut bien entendu obliger à passer par les groupes. Un responsable pourrait être second validateur, ce que pourrait servir en cas d'absence du premier responsable.

prytoegrian commented 8 years ago

Okay...

prytoegrian commented 8 years ago

Non, désolé, je lâche pas l'affaire. Actuellement, dans le code et l'interface que j'ai sous les yeux, on peut mettre :

et je tiens vraiment à poser les choses à plat pour réfléchir à une organisation plus lisible pour nos clients. Il ne faut pas oublier que la notion de « responsable de responsable » va disparaître si on nous rendons obligatoire les groupes, car ils vont se faire remplacer par un système de couche de groupes.

Comme je pense que j'ai dû mal m'exprimer, je repose ma question : quelles raisons feraient qu'on ne pourrait pas définir en tant que second validateur uniquement un DRH ?

À mon sens, la gestion des groupes pourraient avoir les règles métiers suivantes :

Shadok commented 8 years ago

Pas forcément. Pour les grosses boîtes qui ont un DRH, oui, cela fait sens qu'il soit le second validateur. Mais pas que.

Pour les petites boîtes, on peut imaginer le gérant comme second validateur.

Mais dans certains équipes, tu peux avoir N+1, N+2 et N+3, donc le second validateur peut-être le N+2.

prytoegrian commented 8 years ago

Pour les petites structures, le gérant ne fera pas office de DRH ? (au sens de LT j'entends)

Shadok commented 8 years ago

Effectivement, cela revient au même.

wouldsmina commented 8 years ago

Non, désolé, je lâche pas l'affaire.

Et tu fais bien ;)

le DRH Y (celui a les droit RH) en premier validateur et le responsable Z en second validateur

Le DRH a accès à tous les utilisateurs et à toutes les demandes.

Il ne faut pas oublier que la notion de « responsable de responsable » va disparaître si on nous rendons obligatoire les groupes, car ils vont se faire remplacer par un système de couche de groupes.

le grand responsable est défini dans la gestion des groupes, il n'est pas forcément le responsable du responsable :o . (on devrait discuter de cela sur irc pour bien se comprendre...)

Le responsable du responsable (je parle du responsable définit dans la gestion de l'utilisateur) n'est sollicité que lorsque le responsable est absent lors d'une demande. Par contre cette fonction n'est pas implémentées correctement, un mail est transmis au responsable du responsable pour l'informer d'une demande mais il ne peut pas la traiter. Le faire sauter (au moins temporairement) ne me choque donc pas.

quelles raisons feraient qu'on ne pourrait pas définir en tant que second validateur uniquement un DRH ?

Je vois le DRH comme une personne aillant accès a tous les utilisateurs, groupes, demandes, stats...

Shadok commented 8 years ago

Et dans tout ça, quelqu'un peut-il me dire où je peux trouver le laissez-passer A38 ?

prytoegrian commented 8 years ago

Le responsable du responsable (je parle du responsable définit dans la gestion de l'utilisateur) n'est sollicité que lorsque le responsable est absent lors d'une demande.

J'entends bien, seulement si les groupes sont obligatoires, ça fait doublon. Le cas que tu évoques peut être simplement adapté en :

Ok, je vois où vous voulez en venir. Dans ce cas le DRH est quoi ? Juste un rôle de supervision ?

@Shadok Deuxième étage 4° porte à gauche. Te trompe pas, la 3° porte c'est les toilettes des dames

le DRH Y (celui a les droit RH) en premier validateur et le responsable Z en second validateur

Le DRH a accès à tous les utilisateurs et à toutes les demandes.

Ça n'en fait pas un process logique. Là ça dit « la décision prise par le DRH peut être révoquée par n'importe quel responsable », j'imagine pas l'ambiance au bureau ^^

prytoegrian commented 8 years ago

Ah oui, vu qu'on est dans les règles, sur l'édition de groupe (au sens large, modif comme ajout) :

Nous n'avons pas parlé des groupes dans leur globalité. Puisqu'on doit coller à l'interface actuelle, je mettrais deux onglets : Gestion des groupes et Ajout de groupe, avec l'idée qu'à terme ces deux onglets fusionnent, comme les autres. Les pages d'édition font apparaître tout ce qui est nécessaire à l'édition de groupe, à savoir :

Je ne sais pas ce qui est mieux, que l'on conserve la possibilité d'avoir plusieurs premiers (/ second) responsable ou obliger l'unicité.

Quoiqu'il en soit, avoir une telle interface sera plus lisible pour les clients.

wouldsmina commented 8 years ago

Lorsque le responsable est absent lors d'une demande on ne fait rien (quand j'envoie un mail à mon boss et qu'il est pas là, bah j'attends)

+1

Ok, je vois où vous voulez en venir. Dans ce cas le DRH est quoi ? Juste un rôle de supervision ?

idéalement, il gère les traitements globaux (établi les règles de l'entreprise, fermeture, jours fériés....) et les ressources humaines :D , je veux dire par la qu'il a accès à tous les utilisateurs (traitement des demandes, consultation d'un utilisateurs, édition de récap, calendrier, tout quoi).

Ah oui, vu qu'on est dans les règles, sur l'édition de groupe (au sens large, modif comme ajout) : si le groupe est défini comme à double validation, le second validateur est obligatoire,

+1

si des demandes sont en cours sur les employés du groupe, les changements de responsables sont interdits, si des demandes sont en cours sur un employé du groupe, sa sortie du groupe est interdite,

Pour ce calquer sur la réalité : Annulation des demandes, plutôt qu'interdire le changement. D'autant que si le responsable "précédent" accepte des demandes, de l'employé qui change de groupe, sur la période du nouveau responsable, c'est pas bon...

si des demandes sont en cours sur un employé, son entrée dans le groupe est interdite.

Si on considère qu'un employé ne peut être que dans un seul groupe, il ne peut avoir des demandes en cours sans groupe, selon la règle précédente, mais ça reste vrai...

si des demandes sont en cours sur les employés du groupe, on ne peut pas changer le type de validation du groupe,

+1

on peut avoir des groupes vides ?

je dirais non, même dans le cas de groupe peuplé qu'une période dans l'année (des saisonniers par exemple) les utilisateurs ne sont pas supprimés mais désactivés, donc le groupe ne serait pas vide...

je mettrais deux onglets : Gestion des groupes et Ajout de groupe, avec l'idée qu'à terme ces deux onglets fusionnent, comme les autres.

Pourquoi ne pas un onglet dés le départ?

prytoegrian commented 8 years ago

Pour ce calquer sur la réalité : Annulation des demandes, plutôt qu'interdire le changement. D'autant que si le responsable "précédent" accepte des demandes, de l'employé qui change de groupe, sur la période du nouveau responsable, c'est pas bon...

Ok, dans ce cas une petite mention devra être affichée (peut être avec la liste des demandes annulées), pour garantir qu'ils ont bien conscients des conséquences.

Si on considère qu'un employé ne peut être que dans un seul groupe, il ne peut avoir des demandes en cours sans groupe, selon la règle précédente, mais ça reste vrai...

Tout à fait, je l'ai vu comme une sécurité en plus. C'est une règle métier qui ne devrait pas être difficile à coder et ça garanti l'existence plutôt que la voir comme une conséquence d'une autre. En cas de bug de la première règle, on aura l'air bête sinon.

Pourquoi ne pas un onglet dés le départ?

Le problème c'est le code existant. J'adorerai avoir un onglet unique, mais ailleurs dans l'appli c'est comme ça. Si on en change un, faut tous les changer, pour que l'expérience utilisateur aie des règles compréhensibles.

wouldsmina commented 8 years ago

Ok, dans ce cas une petite mention devra être affichée (peut être avec la liste des demandes annulées), pour garantir qu'ils ont bien conscients des conséquences.

j'irais même plus loin, le/les employés sont informés par mail.

prytoegrian commented 8 years ago

Effectivement, j'avais oublié ça, c'est pas bête.

Autre règle :

LRCorwin commented 8 years ago

Hello,

c'te migraine qui s'annonce à lire ce fil !! :)

Bon, cette discussion est super intéressante, mais je pense qu'un bon schéma clarifierait un peu les règles sur lesquelles vous bossez.

Dans ma boite, tous les utilisateurs sont forcément dans au moins un groupe, qui dispose d'au moins un responsable. Pour ces groupes, j'ai recréé l'organigramme interne, of course. La logique actuelle : on a "n" employés dans le Groupe A correspondant au département A M est chef du département, et N est son adjoint : ils sont tous deux dans le groupe A-chefs, et sont tous deux responsables du Groupe A P est chef de Pole qui inclut les départements A, B et C, R est son adjoint Tous deux sont responsables des groupes A-chefs, B-Chefs etc etc Toto du groupe A pose un congé : M et N sont absents (missions, formations, rtt, que sais-je)

Est-ce que dans la logique que vous souhaitez mettre en place, la demande remonte jusqu'à P et R ?

Pas de chaine circulaire, je vote pour. Pas de responsable de compte au moment de l'import/création du user, je vote pour aussi.

Ensuite, autre point qui me parait important, c'est que j'appuie aujourd'hui sur la gestion des groupes pour obtenir différents calendriers (d'où mon "au moins un groupe" ci-dessus). Je m'explique (ou essaie) : Le Comité de Direction souhaite afficher et pouvoir imprimer un calendrier faisant apparaître les chefs de service, leurs adjoints et certains autres responsables. Comme ces personnes sont ventilées dans différents groupes qui représentent leur affectation fonctionnelle, j'ai crée un groupe "_CAL_CoDir", sans responsable, afin que ses membres puissent disposer d'un calendrier à eux. Si vous optez pour l'obligation de n'apparaître que dans un seul groupe, ça va poser problème.

Si je suis super confus, faîtes signe : j'essayerai de faire un dessin...

Merci !

wouldsmina commented 8 years ago

salut @LRCorwin,

Est-ce que dans la logique que vous souhaitez mettre en place, la demande remonte jusqu'à P et R ?

en d'autre terme : un employé fait une demande un jour ou le responsable est absent, est ce que le responsable de ce dernier pourra traiter la demande?

ça risque d’être compliqué car le "responsable du responsable" n'a pas de droit sur le groupe du demandeur. Par contre, lors d'une double validation, le grand responsable pourra traiter directement la demande si le responsable est absent...

M est chef du département, et N est son adjoint : ils sont tous deux dans le groupe A-chefs, et sont tous deux responsables du Groupe A

Tu soulève un point intéressant. Il arrive souvent que l'adjoint ou le secrétaire d'un responsable soit chargé de traiter les demandes. Il faudra donc permettre d'avoir plusieurs responsables pour un groupe.

Le Comité de Direction souhaite afficher et pouvoir imprimer un calendrier faisant apparaître les chefs de service, leurs adjoints et certains autres responsables. Comme ces personnes sont ventilées dans différents groupes qui représentent leur affectation fonctionnelle, j'ai crée un groupe "_CAL_CoDir", sans responsable, afin que ses membres puissent disposer d'un calendrier à eux. Si vous optez pour l'obligation de n'apparaître que dans un seul groupe, ça va poser problème.

Nous y avons un peu réfléchi. l'idée c'est que le responsable ne soit plus nécessairement membre du groupe. Il pourra donc être responsable d'un groupe et membre d'un autre groupe...

LRCorwin commented 8 years ago

Salut,

au niveau du "chainage" des responsabilités, il y a pourtant une option dans la config qui fait qu'en cas d'absence, on remonte d'un cran. Ce point serait abandonné ? Le problème, si on passe à une gestion en double validation, c'est que le Grand Responsable qui n'est aujourd'hui sollicité que de manière marginale va se retrouver "forcé" à valider toutes les demandes.

Ensuite, "responsable d'un groupe et membre d'un autre groupe", c'est parfait : c'est déjà ainsi que je fonctionne. MAIS ce ne sera pas suffisant pour permettre un regroupement "fonctionnel" qui puisse afficher un calendrier global où l'on affiche des utilisateurs d'un certain niveau (encadrement sup' chez moi) mais qui sont ventilés dans leurs propres groupes. Tu vois l'idée ?

wouldsmina commented 8 years ago

au niveau du "chainage" des responsabilités, il y a pourtant une option dans la config qui fait qu'en cas d'absence, on remonte d'un cran.

En effet, l'option existe mais elle ne fait qu'envoyer un mail au responsable au dessus, après il ne peut pas traiter la demande, du coup ça ne sert pas a grand chose :s

MAIS ce ne sera pas suffisant pour permettre un regroupement "fonctionnel" qui puisse afficher un calendrier global où l'on affiche des utilisateurs d'un certain niveau (encadrement sup' chez moi) mais qui sont ventilés dans leurs propres groupes. Tu vois l'idée ?

Non, je suis pas sur de comprendre. si tu veux, on peut en discuter sur irc : https://client02.chat.mibbit.com/?url=irc%3A%2F%2Firc.tuxfamily.org%2FLibertempo

LRCorwin commented 8 years ago

Ah ? Pourtant je peux t'affirmer que chez nous, ça fonctionne... Du coup, tu me mets un doute sur le mécanisme qui le permet. Néanmoins, dans les faits, on a cette possibilité. Je me demande soudain si ce n'est pas un effet de bord dû à la gestion des groupes.

wouldsmina commented 8 years ago

heu, je pense que c'est lié a ta configuration des groupes oui. J'avais cherché a comprendre le mécanisme qui permettait de transmettre les demandes au "resp du resp" et je n'avais trouvé que le traitement du mail, rien ne permet d'afficher la demande...

Peux tu vérifier et confirmer, juste pour etre sur que je n'avais pas raté un truc...

LRCorwin commented 8 years ago

oui, je vais regarder ça. Mais je rappelle au passage que j'ai un Libertempo qui est basé sur une succession de mise à jour depuis Php_congés-1.5. Il y a peut-être des phénomènes (on en a parlé sur d'autres sujets) qui sont dus à cela.

LRCorwin commented 8 years ago

re-

nlle instance 1.8.1, from scratch, sur une VM jessie. Je confirme : -- dans la config, on a en "06" : ### // PRISE EN COMPTE DES ABSENCES DU RESPONSABLE : //-------------------------------------------------------------------------------------------- // si à FALSE : en cas d'absence de leur responsable, les demandes des utilisateurs attendent le retour de celui-ci. (FALSE est la valeur par défaut) // si à TRUE : en cas d'absence de leur responsable, les demandes des utilisateurs sont transmises au responsable du responsable qui peut alors les traiter. qui semble fonctionner parfaitement. Mais une fois encore, j'ai des relations de groupes et de responsables un peu particulière.

En passant, un dump de ma base en prod, et import dans celle de la Nlle instance se passe très bien. Et sur cette nlle instance, si la version imprimable du calendrier est toujours monochrome, au moins le PDF est-il correct.

Pour la suite, suivant la discussion que l'on a eu ce matin sur IRC, je comprends qu'il faudra attendre la 1.9 avec la refonte de la logique Responsable de compte VS Responsable de groupe.

wouldsmina commented 8 years ago

ok. Alors je vais creuser un peu plus pour être sur que je ne dit pas de betise!

je comprends qu'il faudra attendre la 1.9 avec la refonte de la logique Responsable de compte VS Responsable de groupe.

Ouaip, sauf que ce ne sera pas dans la 1.9, on a pas encore décidé sur quelle version on allait revoir les groupes...

LRCorwin commented 8 years ago

Ok : bon, eh bien, on sera un peu plus patient alors !

LRCorwin commented 8 years ago

Bonjour,

y a-t-il un moyen de communiquer par mail avec vous deux, les mainteneurs de la solution ? Au sujet d'une proposition de dev. autour de LiberTempo...

merci

Le 25 août 2016 à 15:52, wouldsmina notifications@github.com a écrit :

ok. Alors je vais creuser un peu plus pour être sur que je ne dit pas de betise!

je comprends qu'il faudra attendre la 1.9 avec la refonte de la logique Responsable de compte VS Responsable de groupe.

Ouaip, sauf que ce ne sera pas dans la 1.9, on a pas encore décidé sur quelle version on allait revoir les groupes...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/wouldsmina/Libertempo/issues/219#issuecomment-242394019, or mute the thread https://github.com/notifications/unsubscribe-auth/ARXwvYYJDtry72hV6PuyOj4J0aiNnt72ks5qjZ4fgaJpZM4JapFT .

wouldsmina commented 8 years ago

ouaip, tu as la liste de diffusion : libertempo@lists.tuxfamily.org a+

wouldsmina commented 8 years ago

finalement la gestion des responsables absent est tout à fait fonctionnelle : https://github.com/wouldsmina/Libertempo/blob/develop/fonctions_conges.php#L1020

Je vais devoir reprendre #215...

sbdUPJV commented 8 years ago

Pour faire suite à #234 je décris le mode de fonctionnement dans notre université : "les employés peuvent-être membres d'un ou plusieurs services". Je donne un exemple, un employé peut très bien travailler dans une scolarité d'une UFR (en gros une faculté), par exemple scolarité de l' U.F.R d'Economie et de Gestion pour une quotité de 50%, avec un responsable au sein de ce service, et à 50% dans la scolarité scolarité de l' U.F.R de Droit avec un autre responsable. Il y a donc 2 personnes qui peuvent valider les congés, et qui au moins doivent être au courant de la demande. Ils ont leur mot à dire également sur les jours d'ARTT et doivent voir ces employés dans le calendrier du groupe. Il y a de nombreux services potentiels et il serait parfaitement envisageable d'imaginer un ou une secrétaire qui travaillerait pour plusieurs laboratoires de recherche, donc autant de responsables potentiels.

prytoegrian commented 8 years ago

Je viens de penser qu'il faudra prévoir un script de migration de l'ancien système (on choisit le responsable dans le profil de l'employé) vers le nouveau avec les groupes obligatoires.

Sinon, au vu de ce que dit @sbdUPJV et des signes que nous avons un peu partout (ici, dans la meuleu, etc), je me rends compte que le fait qu'un employé soit dans plusieurs groupes en simultanée est une fonctionnalité très utilisée. Enfin, suffisamment pour ne plus être catégorique dans la restriction. Par contre, il n'est actuellement pas possible de choisir la quotité d'un employé dans un groupe précis.

sbdUPJV commented 7 years ago

Ce qui serait aussi utile (dans le cas d'une organisation comme la mienne ce serait même primordial), c'est qu'il y ait une notion de DRH sur un groupe donné, pas sur tout le monde. Je m'explique, chez nous il y a plus de 1000 personnes à gérer, une seule personne à la DRH qui gère l'appli de congés (pas à plein temps), et différents (nombreux) pôles auxquels sont affectés les personnels. Il serait intéressant de pouvoir créer des groupes et d'avoir un rôle de "mini" DRH pouvant gérer les fiches (soldes, ARTT, etc.) car ce sont ces personnes qui ont l'information en direct en cas de changement, et c'est donc à eux de pouvoir la mettre à jour.

wouldsmina commented 7 years ago

L'urgence sur ce ticket ce fait un peu plus fort : avec la refonte du traitement des demandes, lorsque qu'un responsable est aussi employé dans un même groupe (ce qui me semble pas logique du tout déjà), il est considéré comme étant soumis à double validation alors que ce n'est pas le cas. J'ai bien essayé de corrigé cela, au moment ou la demande est traitée, mais cela n'a apporté que plus de problème.

wouldsmina commented 7 years ago

voici les points que je compte mettre en oeuvre pour Kantra :

Sur le dernier point, cela sous entend qu'un groupe simple peut ne pas avoir de responsable, auquel cas les employés membre d'un tel groupe sont automatiquement validé.

Je cherche encore la bonne méthode pour permettre de rectifier les cas ou un responsable serait déja membre de son groupe, lors de la mise à jour.

prytoegrian commented 7 years ago

Oublie pas toutes les autres règles qu'on a évoquées au-dessus, comme l'interdiction de la responsabilité circulaire, ce serait dommage de les laisser de côté.

Pour ma part, je le sortirais, directement. Peut-être avec un « rapport d'erreur » lors de la mise à jour sur ce qu'il faut faire post-maj pour stabiliser l'appli, donc les employés à remettre dans un groupe.

wouldsmina commented 7 years ago

l'interdiction de la responsabilité circulaire

tout a fait! je l'ajoute a ma liste...

Oublie pas toutes les autres règles qu'on a évoquées au-dessus

oui, bien sur je ne les oublie pas. Mais certaines ne pourront finalement pas être appliqué (un employé dans un groupe unique par exemple...)

wouldsmina commented 7 years ago

j'ajoute que toute la gestion des groupes se fera depuis un onglet, l'idée fut écarté auparavant mais les chose ont changé depuis (cf. #339).

prytoegrian commented 7 years ago

Suite au merge de la PR, on clot ?

wouldsmina commented 7 years ago

non, il reste encore quelques points à mettre en oeuvre avant :

Ce sera pour mondaran.