Affectation du responsable : Gestion des groupes #219
Comments
|
+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. |
|
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). |
|
@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) ? |
|
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). |
|
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 ? |
|
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. |
|
Sinon, pour la question, il faut bien entendu obliger à passer par les groupes. |
|
Okay... |
|
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 :
|
|
Pas forcément. Pour les grosses boîtes qui ont un DRH, oui, cela fait sens qu'il soit le second validateur. 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. |
|
Pour les petites structures, le gérant ne fera pas office de DRH ? (au sens de LT j'entends) |
|
Effectivement, cela revient au même. |
Et tu fais bien ;)
Le DRH a accès à tous les utilisateurs et à toutes les demandes.
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.
Je vois le DRH comme une personne aillant accès a tous les utilisateurs, groupes, demandes, stats... |
|
Et dans tout ça, quelqu'un peut-il me dire où je peux trouver le laissez-passer A38 ? |
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
Ç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 ^^ |
|
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. |
+1
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).
+1
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 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...
+1
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...
Pourquoi ne pas un onglet dés le départ? |
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.
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.
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. |
j'irais même plus loin, le/les employés sont informés par mail. |
|
Effectivement, j'avais oublié ça, c'est pas bête. Autre règle :
|
|
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. 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. 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). Si je suis super confus, faîtes signe : j'essayerai de faire un dessin... Merci ! |
|
salut @LRCorwin,
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...
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.
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... |
|
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. 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. |
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
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 |
|
Ah ? Pourtant je peux t'affirmer que chez nous, ça fonctionne... |
|
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... |
|
oui, je vais regarder ça. |
|
re- nlle instance 1.8.1, from scratch, sur une VM jessie. 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. |
|
ok. Alors je vais creuser un peu plus pour être sur que je ne dit pas de betise!
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... |
|
Ok : bon, eh bien, on sera un peu plus patient alors ! |
|
Bonjour, y a-t-il un moyen de communiquer par mail avec vous deux, les mainteneurs merci Le 25 août 2016 à 15:52, wouldsmina notifications@github.com a écrit :
|
|
ouaip, tu as la liste de diffusion : libertempo@lists.tuxfamily.org |
|
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... |
|
Pour faire suite à #234 je décris le mode de fonctionnement dans notre université : |
|
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. |
|
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. |
|
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. |
|
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. |
|
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. |
tout a fait! je l'ajoute a ma liste...
oui, bien sur je ne les oublie pas. Mais certaines ne pourront finalement pas être appliqué (un employé dans un groupe unique par exemple...) |
|
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). |
|
Suite au merge de la PR, on clot ? |
|
non, il reste encore quelques points à mettre en oeuvre avant :
Ce sera pour mondaran. |
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)...
The text was updated successfully, but these errors were encountered: