J'ai regardé le plugin additionalAlert, qui me semble peut-être un peu trop
figé, en opposition à mon projet, et je vais essayer, en quelques lignes ici de
vous expliquer la manière dont j'ai procédé.
Bien qu'au sein de mon plugin, un panel de types d'alerte sera pré-enregistré,
j'ai pensé ce plugin pour que d'autres plugins puissent générer des alertes
simplement en ajoutant une ligne "bien construite" dans ma table d'alerte.
Cette table d'alerte contient les champs suivants (hormis ceux obligatoire):
• Item (pour une règle sur les espaces disque, l'objet serait Computer,
champ purement informel);
• Id de la catégorie (pour le même exemple, la catégorie serait " Disque
dur ", elle même pouvant être enfant d'une autre catégorie, etc..);
• Unité de mesure (pour le même exemple, nous mettrions " Mo ", purement
informel);
• Un typage (pouvant être soit : text,date,int,bool, pour ce cas, Int
serait choisie )
• Une dimension (données numérique à logique binaire), cette info permet de
connaître les environnement dans lesquels la requête est possible, les choix
suivant sont possibles :
• 1 : Pour chaque Element (pour l'exemple, pour chaque Disque dur).
• 2 : Pour chaque objet (pour l'exemple, pour chaque ordinateur) .
• 4 : Pour chaque utilisateur (explicite).
• 8 : Pour chaque entité.
La dimension serait alors, pour cet exemple, de 15, soit tous les environnement
possibles.
Enfin, la données la plus importante est la structure, et c'est celle qui
permet d'en ressortir une requête SQL.
la structure a pour but de déterminer :
• Les tables à joindres;
• La localisation des information de type : users_id, entities_id;
• le champ à comparer.
Cette structure sera donc un tableau, serialisé, qui ressemblera, pour cet
exemple, à ceci :
array(1) {
["glpi_computers"]=>
array(3) {
["users_id"]=>
int(1)
["entities_id"]=>
int(1)
["glpi_computerdisks"]=>
array(3) {
["prefix_table"]=>
int(0)
["group_field"]=>
int(0)
["field"]=>
string(60) "(glpi_computerdisks.totalsize - glpi_computerdisks.freesize)"
}
}
}
Ici, et une fois analysé, le plugin comprend :
• Que l'objet est glpi_computers;
• Que le champ à comparer se situe dans glpi_computerdisks;
• qu'il ne doit pas prefixer le champ de son nom de table;
• que les notions d'utilisateur et d'entité sont à récolter dans la table
glpi_computers;
• Qu'il n'y a pas de champs spécifique à comparer si la dimension est de
type "objet","utilisateur" ou "entité".
Voilà, j'espère que cette explication est aussi clair pour vous que pour moi !
Et je suis bien sûr preneur de toute remarque !
Anthony HEBERT
----- Mail Original -----
De: "Tsmr" <t...@thetsmr.fr>
À: "Liste de diffusion des developpeurs GLPI" <glpi-dev@gna.org>
Envoyé: Mercredi 20 Octobre 2010 17:50:44
Objet: Re: [Glpi-dev] Demande d'ouverture d'un projet
On Wed, 20 Oct 2010 17:21:11 +0200, Remi Collet <fed...@famillecollet.com>
wrote:
> Le 20/10/2010 17:12, Anthony Hebert a écrit :
>> Bonjour à tous,
>>
>> Voilà j'aimerais vous demander l'ouverture sur la forge d'un projet pour
>> mon plugin nommé : alertmaker.
>>
>> Ce plugin permet d'une manière générale de créer des règles d'alertes,
>> semblables à celle des alertes sur les cartouches.
>
> Ne serait-il pas préférable d'étendre les fonctionalités du plugin
> "alerting" ?
> Tsmr ?
>
>
> +
>
>
> _______________________________________________
> Glpi-dev mailing list
> Glpi-dev@gna.org
> https://mail.gna.org/listinfo/glpi-dev
Oui en lisant c'est tout de suite ce que je me suis dit. :P
_______________________________________________
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev
_______________________________________________
Glpi-dev mailing list
Glpi-dev@gna.org
https://mail.gna.org/listinfo/glpi-dev
