Custom des champs

fabche · 2010-11-04 11:03:37

Bonjour,

J'ai du modifier le code pour faire un truc tout bête mais très utile, je me suis dit autant y mettre sur le fofo ...
Puis j'ai eu une autre idée

Pour les téléphones j'ai recensé les portables et DECT et autre ...

Et ce qui est important pour les portables c'est le numéros carte SIM et code PUK qui peuvent etre trés utile ....
J'ai donc fait une modife tout basique en remplaçant les traduction de champs inutile pour moi ...

D'où est venue mon idée ...
Permettre a l'utilisateur qui ne connait pas le php d'avoir 1 ou 2 champs customisé pour renseigné les données qu'il veut.
Je ne sait pas si cela est dur a faire pour nos amis développeur ...
Et si je me suis bien fait comprendre ...

Merci de m'avoir lu et pour vos remarques

Last edited by fabche (2010-11-04 11:06:06)

Florian Benavent · 2010-11-04 11:13:32

Bonjour,

Simple, simple, je pense pas....
Il faudrait réaliser une interface ou l'utilisateur pourrait nommer les champs et choisir ou les appliquer (téléphone-ticket-etc.., sa servirai à rien de le faire qu'à moitié, aussi dur pour un résultat moindre) et ou l'utilisateur pourrait entrer des traductions différentes (comme pour les notifications sur la version 0.78).

Après il faudrait stocker ces nouvelles traduction et leur champs d'intervention (Rajouter les traductions dans les fichiers langues et dans la base de donnée les ciblés avec un champ utilisation en parallèle, ou directement le tout dans la base de donnée.)

ça encore c'est pas le plus compliqué (et déjà y a de quoi faire).

Ensuite il faut modifier l'ensemble du code pour y rajouter une recherche permettant d'afficher ou non un nouvelle élément (selon son existence) en évitant de laisser des espaces blanc si l'utilisateur n'en à pas défini...

Au final sa fait un logiciel de développement pour GLPI directement :x

Actuellement c'est pas trop compliqué je trouve, et des connaissances en php ne sont pas nécessaire pour changer un intitulé (locales -> fichier langue (votre langue est plus simple)-> rechercher l'intitulé que vous voulez changer-> changez-le-> sauvegarder->actualiser GLPI, si il à pas changé -> retourner dans le fichier (que vous aurez pas fermé) -> ctrl +z et cherchez une autre occurrence de cette intitulé dans cette page pour répéter l'opération).
Une fois le champ trouvé sur un fichier, il suffit de se servir de son "nom" (== LANG['nom'][x]) pour modifier sur l'ensemble des fichiers et fini !.

Après si y à des gens motivé pour le faire, bonne chance.
Florian

Last edited by Florian Benavent (2010-11-04 11:14:35)

fabche · 2010-11-04 11:55:02

Florian Benavent wrote:

Bonjour,
Simple, simple, je pense pas....
Il faudrait réaliser une interface ou l'utilisateur pourrait nommer les champs et choisir ou les appliquer (téléphone-ticket-etc.., sa servirai à rien de le faire qu'à moitié, aussi dur pour un résultat moindre) et ou l'utilisateur pourrait entrer des traductions différentes (comme pour les notifications sur la version 0.78).
Après il faudrait stocker ces nouvelles traduction et leur champs d'intervention (Rajouter les traductions dans les fichiers langues et dans la base de donnée les ciblés avec un champ utilisation en parallèle, ou directement le tout dans la base de donnée.)
ça encore c'est pas le plus compliqué (et déjà y a de quoi faire).
Florian

Après on peut faire plus simple sans aller dans l'extrême flo,

Si un champ est libre et que je l'appelle "Numéros Sim" c'est juste pour mon usage personnel inutile de s'amuser avec un fichier traduction ...

Florian Benavent wrote:

Ensuite il faut modifier l'ensemble du code pour y rajouter une recherche permettant d'afficher ou non un nouvel élément (selon son existence) en évitant de laisser des espaces blanc si l'utilisateur n'en à pas défini...
Au final sa fait un logiciel de développement pour GLPI directement :x

Florian

La aussi il y a plus simple, ce sont 2 champs supplémentaires qui peuvent aider pour un renseignement, faire complètement la même infrastructure que les autre pour ces demande est aussi trop …
C’est sur que si on pouvait après rajouter les colonnes, faire la recherche, ce serait mieux mais la oui c’est trop long….

Et les espace blanc ce n’est pas ce qui gêne même les champs fait par glpi certain sont blanc et sa bloque rien

Et oui j’ai aussi modifié la traduction comme tu as fait mais que va-t-il se passé aux Mise à jour ??
Tout sera shooter et retour à la case départ …

Finalement ce que je suggère c’est la création de 4 nouveaux champs vides (2 pour les champs de renseignements voulu et 2 pour la réponse).

Florian Benavent · 2010-11-04 13:07:15

D'avance : toute mes excuses pour la longueur du poste et bonne chance pour le lire.

fabche wrote:

Après on peut faire plus simple sans aller dans l'extrême flo,
Si un champ est libre et que je l'appelle "Numéros Sim" c'est juste pour mon usage personnel inutile de s'amuser avec un fichier traduction ...

Oui mais la tu quitte l'esprit de GLPI qui est multi-langue et ceux qui auront des utilisateurs interagissant avec l'inventaire parlant 2-3 langues différentes (français-anglais, francais-allemand, allemand-anglais, ...) seront embêtes car l'utilisateur verra alors un champ qu'il ne comprend pas (1 c'est pas beau, 2 c'est gênant) .

Et ensuite, pense qu'il faut bien stocker la valeur que tu veut lui donner quelque part, après le fichier traduction ou la base des données c'est au choix :x

fabche wrote:

La aussi il y a plus simple, ce sont 2 champs supplémentaires qui peuvent aider pour un renseignement, faire complètement la même infrastructure que les autre pour ces demande est aussi trop …
C’est sur que si on pouvait après rajouter les colonnes, faire la recherche, ce serait mieux mais la oui c’est trop long….
Et les espace blanc ce n’est pas ce qui gêne même les champs fait par glpi certain sont blanc et sa bloque rien

En effet ce que j'ai proposé est compliqué et long, mais cela permet une la personnalisation maximum (pour ce sujet).
Les champs blancs (qui ne gênent pas l'exécution de GLPI je sait) ne vous gênent pas, mais cela risque d'en gêner d'autre (moi le premier) car cela brise un ensemble carré et propre.

fabche wrote:

Et oui j’ai aussi modifié la traduction comme tu as fait mais que va-t-il se passé aux Mise à jour ??
Tout sera shooter et retour à la case départ …

Je suis d'accord ici c'est embêtant car il faut re-modifier les fichiers langues (en vérifiant que ce sont toujours bien ces champs la.

fabche wrote:

Finalement ce que je suggère c’est la création de 4 nouveaux champs vides (2 pour les champs de renseignements voulu et 2 pour la réponse).

Je ne m'oppose pas à l'idée (ce serait même le contraire) à partir du moment ou ils ne s'affichent pas lorsqu'ils sont vide (un petit if - else et le tour est joué ça de toute façon). Mais on repart sur une grosse modification (que ce soit pour 4 champs ou plus plus) car il faut modifier le code de création d'un objet, d'affichage de l'objet et de modification de l'objet (et ça c'est si on n'ajoute pas ces champs dans les gabarit.

Après il faut bien stocker quelque part (une base de donnée supplémentaire ou existante, cela dépend, ou dans le fichier langue).

Aller je suis motivé : ajout de 4 champs (2 input 2 lang) dans un formulaire prenant chacun une ligne (mais ça sa se change vite fait bien fait pour les 2 cas qui suivent) (la il est tiré du code, les fonctions ne correspondent surement pas, il s'agit d'un exemple, avec disparition en cas de champ vide).
les éléments langues sont :
$LANG['exemple'][1]
$LANG['exemple'][2]

if ($LANG['exemple'][1]) {
echo "<tr class='tab_bg_1'>";
echo "<td>".$LANG['exemple'][1]." : </td>";
echo "<td>";
autocompletionTextField($this,"serial");
echo "</td></tr>";
}
if ($LANG['exemple'][2]) {
echo "<tr class='tab_bg_1'>";
echo "<td>".$LANG['exemple'][2]." : </td>";
echo "<td>";
autocompletionTextField($this,"serial");
echo "</td></tr>";
}

Derrière à modifier le code pour qu'il reçoit bien les données, puis les affichages des actions précédemment cités (affichage-modification)

La même action dans une base de donnée (appelé ici glpi_exemple, contenant : 'id', 'action', 'langue', 'titre') dépendante de l'action que l'on fait :

Dans les fonctions gérant les téléphones:

my_fonction_exemple('phones')

La dite fonction :

function my_fonction_exemple($type)
{
global $CFG_GLPI;
$sql = "SELECT * FROM `glpi_exemple` WHERE `action` =".$type;
$data = mysql_query($sql);
while ($res = mysql_fetch_assoc($data))
{
if ($res['langue'] == $CFG_GLPI['language'] && $res['titre']) {
echo "<tr class='tab_bg_1'>";
echo "<td>".$res['titre']." : </td>";
echo "<td>";
autocompletionTextField($this,"serial");
echo "</td></tr>";
}
}

encore une fois :
Derrière à modifier le code pour qu'il reçoit bien les données, puis les affichages des actions précédemment cités (affichage-modification)

La réception des données sera plus longues mais en 2 fonction (1 réception et 2 utilisation de ces dernières), ensuite les fonctions concernés n'auront plus qu'à les appeler (sauf que les fonctions concernés sont nombreuses, que ce soit avec le code n°1 que n°2).

code n°1: 4 champ ajouter basé sur fichier langue (donc multi-langue)ne s'affichant pas si le champ est vide. Nécessite d'être copié dans l'ensemble des fonctions ou ont désire rajouter les champs.

code n°2 : champ ajouter selon le nombre de champs présent dans la base, champ pouvant être ajouter pour les téléphones, les ordinateur, les ticket, ....., multi-langue, ne s'affichant pas si le champ est vide, ne nécessite qu'un appel aux nouvelles fonctions dans les fonctions désirés.

Derrière faut l'interface de gestion qui est aussi compliqué pour l'une que l'autre (au lieu d'écrire dans une base tu écrit dans le fichier). Cette fois ci je ne fait pas d'exemple, mais croit moi :x

Conclusion : (j'ai terminé mon roman d'aujourd'hui),
Comme je le disait si tu veut appliquer cette modification correctement (sans embêté d'autres utilisateurs par des champs vide ou non traduit), la marche entre ajouter 4 champs et ajouter des champs dynamiquement est petite, pour un résultat nettement supérieur (après c'est sur, si on est parti d'un côté, bah faut tout recommencer pour aller de l'autre et là c'est une perte énorme de temps).
Après cette Amélioration est faisable et utile mais longueee...

Voilou voilou,
Bonne journée
Florian

Important :
A noter : ces "fonctions sont des exemples, et bien qu'elle soit cohérente (normalement) elle nécessiterait des modifications pour être appliqué à glpi", mais il y aura surement autant de modification sur l'une que l'autre donc .

A tout ceux qui auront lu ce poste jusqu'au bout : Félicitation !

Last edited by Florian Benavent (2010-11-04 13:08:22)

onnard · 2010-12-14 13:22:34

C'est vrai que la fonctionnalité de champs custom serait quand même pas mal

J-n-s · 2010-12-15 11:38:10

Petite remarque :
C'est un peu ce que fait le plugin "Champs personnalisés" : https://forge.indepnet.net/projects/customfields
(il permet d'ajouter des champs dans les différentes interfaces...)
Malheureusement il n'est plus maintenu en 0.78 !

onnard · 2010-12-15 12:27:59

Oui tout a fait, et son développeur demande dans les 5000 $ pour le maintenir (il y a un post a ce sujet dans la section anglaise).

Forum GLPI-Project

Announcement

#1 2010-11-04 11:03:37

Custom des champs

#2 2010-11-04 11:13:32

Re: Custom des champs

#3 2010-11-04 11:55:02

Re: Custom des champs

#4 2010-11-04 13:07:15

Re: Custom des champs

#5 2010-12-14 13:22:34

Re: Custom des champs

#6 2010-12-15 11:38:10

Re: Custom des champs

#7 2010-12-15 12:27:59

Re: Custom des champs

Board footer