Bonjour,
Effectivement, cela peut être très complexe. C'est en partie pour cela
que je ne suis pas allé plus loin qu'une simple proposition pour faire
évoluer CommonDBChild.
Mais je pense que ce patch sera utile pour le numéro de téléphone, sauf
dans le deriner cas que tu décris (Item_Phone).
Damien
On 16/12/2012 08:51, Julien Dombre wrote:
Bonjour,
Attention le ticket 3351 n'est pas si évident que cela.
La spécification complète n'a pas été réalisé et plusieurs choix sont
encore possibles.
Pour résumé la problématique soit :
- on extrait simplement l'information téléphone (gestion somple comme
UserEmail)
- le numéro de téléphone devient un vrai objet rattachable à un User,
un Contact, un Fournisseur voir à une Entité... Le numéro pourrait
être typable (fixe, portable, fax...) mais typable avec des choix
fixes ou via un dropdown ? Ensuite un numéro pourrait être également
lié de l'autre côté à un téléphone dans l'inventaire.
Bref, du ticket simple posé intialement, la problématique peut être
beaucoup plus complexe.
++
Julien
Le 16/12/2012 07:26, Damien Touraine a écrit :
Bonjour,
J'ai essayé de réfléchir au ticket 3351. Je pense avoir trouver une
solution élégante : on centralise l'affichage d'un "petit" enfant
(mail, téléphone, adresse IP) sur une grosse classe tout en laissant
une certaines autonomie à la classe pour redéfinir ses propres
attributs (is_default pour UserEmail, et prochainement : is_DHCP pour
l'adresse IP). J'ai attaché un premier patch au ticket. Dans la
foulée, il permet de choisir dès la création d'un e-mail celui par
défaut.
Qu'en pensez-vous ?
Damien
_______________________________________________
Glpi-dev mailing list
[email protected]
https://mail.gna.org/listinfo/glpi-dev
_______________________________________________
Glpi-dev mailing list
[email protected]
https://mail.gna.org/listinfo/glpi-dev
_______________________________________________
Glpi-dev mailing list
[email protected]
https://mail.gna.org/listinfo/glpi-dev
