affectation massive des utilisateurs à une entité

ALieN · 2007-05-03 14:35:15

mma75 wrote:

MoYo wrote:
heu non pourquoi ?
L'affectation des machines à une entité au moment de l'import OCS. Dans un mode sans OCS ca veut dire que vous devez juste crééer manuellement vos machines dans la bonne entité ce qui n'est pas un problème.
heu oui... mais si les machines on déja été créé dans la V 0.68, pouvoir appliquer des régles basées sur les champs GLPI serait un plus non ?

Effectivement, le problème se pose si à l'heure actuelle nous n'utilisons plus OCS et nous avons 1200 machines à affecter à une entité, rien n'est prévu dans ce cas la.

j'imagine assez mal de devoir tout supprimer et recommencer un inventaire complet à la mano, ou devoir réinstaller OCS pour réimporter toutes les machines.

MoYo · 2007-05-03 14:46:01

Vous pourrez de toute facon pour le moment utiliser la 0.7 sans multi-entités jusqu'à la finalisation de la problématique transfert de machines.

Ce qui est clair c'est que la 0.7 change la vision que l'on pouvait avoir de GLPI.
La multi-entité apporte un grand plus mais migrer d'une base existante à une base multi-entités 0.7 est complexe.

ALieN · 2007-05-03 16:45:40

MoYo wrote:

Vous pourrez de toute facon pour le moment utiliser la 0.7 sans multi-entités jusqu'à la finalisation de la problématique transfert de machines.
Ce qui est clair c'est que la 0.7 change la vision que l'on pouvait avoir de GLPI.
La multi-entité apporte un grand plus mais migrer d'une base existante à une base multi-entités 0.7 est complexe.

Est ce que le projet "transfert de machines" est prévu pour être intégrer avec la sortie de la version 0.7 ou est ce que cela fera partie d'une greffe future ?

mma75 · 2007-05-03 16:52:21

Effectivement la problèmatique de transfert peut être complexe à implémenter. pour moi, un utilisateur ne part pas avec sa machine s'il est muté dans une autre entité, cependant je dois pouvoir tranferer une machine de l'agence A, sous entité hiérarchique de l'entité A, vers l'agence B de l'entité A. l'entité A étant toujour le référent budgétaire

Comme il est précisé dans le wiki le problème ce pose bien au point de vu financier et l'affectation de l'élément à une entité reste une donnée identique à celle du lieu. pourquoi de pas implémenter dans un premier temps uniquement la gestion des droits liés à l'entité (tout ce qui est attaché à un pc suis ce pc). et laisser la gestion financiere ?

Glpi arrive aujourd'hui comme tu le dis à un tournant, reste à savoir si vous souhaiter orienter l'outil vers une utilisation + service desk (compte tenu de la volonté à terme d'intégrer les bonnes pratiques ITIL) ou vers un outil comptable destiner à gérer les immobilisations financierement (fonction déja existante sur certain PGI ou erp open source bien connu) peut être que l'interfacage avec un de ces outils permettrait d'agrandir la chaine open source ??

D'autre part, comment peut on apporter des commentaires dans le wiki autrement que par la ligne annonmymous ?

MoYo · 2007-05-03 17:02:40

en te connectant pour le wiki

emgenet · 2007-05-03 23:08:48

MoYo wrote:

La multi-entité apporte un grand plus mais migrer d'une base existante à une base multi-entités 0.7 est complexe.

Moyo, OK, mais si on veut migrer une base existante, je me voit mal ré-importer tous mes PC alors que le boulot est déjà fait pour les lieux, les écrans.... les tiquets...

mma75 · 2007-05-04 15:02:55

MoYo wrote:

en te connectant pour le wiki

hello
ok il faut un compte compte particulier ???

au fait, tu n'as pas répondu à ma question

A+

MoYo · 2007-05-04 18:18:34

emgenet : oui je comprend bien mais pour le moment il faut rester en mode mono-entité il n'y a pas le choix.
mma75 : ah non pardon sur celui là vous ne pouvez pas vous connecter tu peux juste te pseudo identifier via Settings a coté de login. C'etait quoi la question ?

mma75 · 2007-06-01 20:19:57

je pense qu'une parti du problème rencontré par certains utilsateurs est liée au fait que la gestion des droits d'accès mis en place par l'association entité / profil / recursivité complique considérablement le problème puisqu'on est obligé de gérer par cela une notion d'organisation avec une notion de droit de visualisation de données.

cette notion d'entité est nécéssaire mais en y associent la notion de profil on bloque tout inter-connexion des données locales qui doivent être vu ou commune à tout le monde ou à plusieurs entités dans certaine organisation (lieu, groupe, serveur, application, logiciel group).

un champs entité (ou nommont le oragnisation interne) devrait peut être être ajouter (aux utilisateurs et inventaires) pour pouvoir gérer une simple affectation d'ordre organistionnelle d'une entreprise tout en laissant la possibilité d'utiliser la séparation des données par la gestion des entités à d'autre. je pense que cela résoudrait les problèmes de certain qui ont détourné des champs de la v 68.3 pour implémenter cette notion d'organisation (lieu, profil.. ou autres champs )

ceci est une simple réflexion qui n'est pas de moi bien sur mais, la notion de profil désigne un ensemble de données necéssaires à l'execution d'une fonction identifiée à des fins d’interopérabilité et pour une méthodologie de référencement des divers usages de ces données, un profil précise les éléments qui doivent être utilisés par un groupe particulier.

L'interopérabilité est le fait que plusieurs systèmes, qu'ils soient identiques ou radicalement différents, puissent communiquer sans ambiguïté et opérer (travailler) ensemble.

les trois données principales de glpi serait les éléments d'inventaire, les personnes, les tickets
un groupe de données secondaires seront les informations qui les précises unitairement, model, no serie, type, catégorisation, priorité, email, no de téléphone
un autre groupe de données serait les éléments qui les regroupes au sein de l'entreprise de maniere commune leur lieu, leur entité d'appartenance, leur groupe de d'appartenance...

les notions d'entité et de récursivité devraient donc être incluse dans le profil et ne pas en être un constituant intrinseque.

JMD · 2007-06-01 22:29:06

mma75 wrote:

je pense qu'une parti du problème rencontré par certains utilsateurs est liée au fait que la gestion des droits d'accès mis en place par l'association entité / profil / recursivité complique considérablement le problème puisqu'on est obligé de gérer par cela une notion d'organisation avec une notion de droit de visualisation de données.

On va insister sur le "Certains utilisateurs". Car clairement les deux très grosses structures qui ont réellement collaboré avec nous sur cette problématique multi-entité (quand je dis collaborer, je dis bien mettre les mains dans le cambouis et mettre des moyens à disposition, pas seulement invoquer le grand "Yaka Fokon") n'ont pas de problème avec cette association puisqu'au contraire elles le souhaitaient...

cette notion d'entité est nécéssaire mais en y associent la notion de profil on bloque tout inter-connexion des données locales qui doivent être vu ou commune à tout le monde ou à plusieurs entités dans certaine organisation (lieu, groupe, serveur, application, logiciel group).

Certes mais si on veut du cloisonnement, il faut bien placer la notion d'imperméabilité à un endroit...
J'ai l'impression que vous concevez la notion d'entité comme une notion de groupe ou de lieu améliorée. Peut-être d'ailleurs que vous n'avez pas besoin de la notion de multi-entité et qu'une simple amélioration de la notion de groupe vous suffirait.

un champs entité (ou nommont le oragnisation interne) devrait peut être être ajouter (aux utilisateurs et inventaires) pour pouvoir gérer une simple affectation d'ordre organistionnelle d'une entreprise tout en laissant la possibilité d'utiliser la séparation des données par la gestion des entités à d'autre.

C'est à dire ?

je pense que cela résoudrait les problèmes de certain qui ont détourné des champs de la v 68.3 pour implémenter cette notion d'organisation (lieu, profil.. ou autres champs )

Bah ça au risque de vous déplaire, c'est leur ou votre problème. Vous utilisez GLPI comme bon vous semble et personne ne vous oblige à passer en 0.7. Certaines structures continuent d'utiliser GLPI dans des versions 0.5 par exemple car cela leur suffit et répond totalement à leur besoin. Mettez-vous quelques minutes à notre place, comment voulez vous que nous puissions prendre en considération les multiples façons dont chacun à fait sa cuisine de GLPI pour le caler sur son organisation interne. Sachant que certaines fois, nous sommes en face d'organisations totalement ubuesques...

ceci est une simple réflexion qui n'est pas de moi bien sur mais, la notion de profil désigne un ensemble de données necéssaires à l'execution d'une fonction identifiée à des fins d’interopérabilité et pour une méthodologie de référencement des divers usages de ces données, un profil précise les éléments qui doivent être utilisés par un groupe particulier.
L'interopérabilité est le fait que plusieurs systèmes, qu'ils soient identiques ou radicalement différents, puissent communiquer sans ambiguïté et opérer (travailler) ensemble.

Ca vient de wikipédia ?

les trois données principales de glpi serait les éléments d'inventaire, les personnes, les tickets
un groupe de données secondaires seront les informations qui les précises unitairement, model, no serie, type, catégorisation, priorité, email, no de téléphone
un autre groupe de données serait les éléments qui les regroupes au sein de l'entreprise de maniere commune leur lieu, leur entité d'appartenance, leur groupe de d'appartenance...
les notions d'entité et de récursivité devraient donc être incluse dans le profil et ne pas en être un constituant intrinseque.

Et on fait quoi des utilisateurs qui ont des profils différents sur plusieurs entités ?

Sérieusement, on casse tout et on recommence ?

MoYo · 2007-06-01 22:39:00

ouep on supprime tout et on refait tout.
Sortie de la 0.7 en 2012.

mma75 · 2007-06-02 09:02:09

effectivement, "...contraire elles le souhaitaient..."

non on ne peut pas revenir en arrière évidement. ceci dit, il y a éventuellement un moyen d'ouvrir glpi, et de palier à ce problème, en incluant dans le profil un droit supplémentaire qui serait "voir les éléments multi entité" oui/non qui peut se traduire par un paramétrage de la vision du global et du local il serait bien d'ailleurs de pouvoir paramétré l'acces multi entité sur un certain nombre de drop table au sein du profil (lieu, groupe, priorité, statut, type matériel......) pour permettre a chacun de choisir s'il souhaite ou non appliquer une dénomination à l'ensemble de ses entités ou au contraire laisser toutes les entreprises qui utiliser indépendamment l'application d'avoir des dénomination propre. tout vos utilisateur non pas forcement la même vision que ces grosses structures dont vous parlez.

cdlt

Last edited by mma75 (2007-06-02 09:20:32)

wawa · 2007-06-02 10:55:37

pourtant c'est pas nouveau cette histoire d'entités, et de plus ça a été écrit sur le wiki depuis le départ...

si ça vous intéressait tant, pourquoi ne pas en avoir parlé avec les devs depuis le début du dev de la 0.70 ? parce que forcément maintenant qu'on a tout fini, ça me parait dur de changer quoique ce soit

nous on a discuté avec eux depuis le départ pour voir comment nos problèmatiques allaient coller, et on s'en sort très bien maintenant

MoYo · 2007-06-02 11:36:52

mma75 wrote:

un paramétrage de la vision du global et du local il serait bien d'ailleurs de pouvoir paramétré l'acces multi entité sur un certain nombre de drop table au sein du profil (lieu, groupe, priorité, statut, type matériel......) pour permettre a chacun de choisir s'il souhaite ou non appliquer une dénomination à l'ensemble de ses entités

Vous ne vous rendez pas compte de ce que ca implique je pense.
Comment gérer cela au niveau du code etc etc.

Parce que bien evidemment au bout d'un moment les personnes elles vont vouloir changer de mode de gestion, par exemple en voulant passer les groupes d'une gestion locale à une gestyion globale ou l'inverse.
Et vous traitez ca comment ?

mma75 · 2007-06-04 11:28:41

wawa wrote:

pourtant c'est pas nouveau cette histoire d'entités, et de plus ça a été écrit sur le wiki depuis le départ...
si ça vous intéressait tant, pourquoi ne pas en avoir parlé avec les devs depuis le début du dev de la 0.70 ? parce que forcément maintenant qu'on a tout fini, ça me parait dur de changer quoique ce soit
nous on a discuté avec eux depuis le départ pour voir comment nos problèmatiques allaient coller, et on s'en sort très bien maintenant

sans doute mais je ne me suis connecter au forum que fin janvier et je m'occupais d'installer la 0.68, la 70 n'était pas au programme

mma75 · 2007-06-04 11:54:32

MoYo wrote:

Vous ne vous rendez pas compte de ce que ca implique je pense.
Comment gérer cela au niveau du code etc etc.
Parce que bien evidemment au bout d'un moment les personnes elles vont vouloir changer de mode de gestion, par exemple en voulant passer les groupes d'une gestion locale à une gestyion globale ou l'inverse.
Et vous traitez ca comment ?

Dans glpi il y a obligatoirement une centralisation d'une partie de l'administration. si les personnes souhaites changer, pourquoi ne pas leur en laissé le choix, elle peuvent en avoir besoin ?

d'une maniere générale, un élément pourrait être considéré comme global s'il est géré par l'entité racine (adminstration centrale), à partir du moment où il est affecté à l'entité racine il est visible de tous à condistion que la personne est un profil "entité racine + profil". cela permettrait également de gérer la possibilité de pouvoir transferer un dossier d'un groupe d'une entité à un groupe d'une autre entité pour certaines personnes autorisées à voir ou gérer les données de l'entité racine.

je vois que dans la gestion des profils, il y a deux onglets de prévus "local" et "global" à quoi cela correspond ?

Last edited by mma75 (2007-06-04 12:05:00)

mma75 · 2007-07-24 19:40:36

je vois que dans la gestion des profils, il y a deux onglets de prévus "local" et "global" à quoi cela correspond ?

serait il possible d'avoir des infos sur le sujet ??

MoYo · 2007-07-24 22:45:19

ce n'est pas 2 onglets mais la légende pour la porté des droits (couleurs de fond)

mma75 · 2007-07-26 08:42:19

ok merci

Forum GLPI-Project

Announcement

#26 2007-05-03 14:35:15

Re: affectation massive des utilisateurs à une entité

#27 2007-05-03 14:46:01

Re: affectation massive des utilisateurs à une entité

#28 2007-05-03 16:45:40

Re: affectation massive des utilisateurs à une entité

#29 2007-05-03 16:52:21

Re: affectation massive des utilisateurs à une entité

#30 2007-05-03 17:02:40

Re: affectation massive des utilisateurs à une entité

#31 2007-05-03 23:08:48

Re: affectation massive des utilisateurs à une entité

#32 2007-05-04 15:02:55

Re: affectation massive des utilisateurs à une entité

#33 2007-05-04 18:18:34

Re: affectation massive des utilisateurs à une entité

#34 2007-06-01 20:19:57

Re: affectation massive des utilisateurs à une entité

#35 2007-06-01 22:29:06

Re: affectation massive des utilisateurs à une entité

#36 2007-06-01 22:39:00

Re: affectation massive des utilisateurs à une entité

#37 2007-06-02 09:02:09

Re: affectation massive des utilisateurs à une entité

#38 2007-06-02 10:55:37

Re: affectation massive des utilisateurs à une entité

#39 2007-06-02 11:36:52

Re: affectation massive des utilisateurs à une entité

#40 2007-06-04 11:28:41

Re: affectation massive des utilisateurs à une entité

#41 2007-06-04 11:54:32

Re: affectation massive des utilisateurs à une entité

#42 2007-07-24 19:40:36

Re: affectation massive des utilisateurs à une entité

#43 2007-07-24 22:45:19

Re: affectation massive des utilisateurs à une entité

#44 2007-07-26 08:42:19

Re: affectation massive des utilisateurs à une entité

Board footer