Hello, (French version after)
So we work on the ticket part of glpi and we discover a "fun" thing
[For information in Our product me make a little graphique evolution(in
"Suivi" the link to the ticket Detail is no more on the -Info- label , the
link is placed on the title of the ticket (this is a little bit more
natural and make more place because we can remove Info column so the
proposed patch will not be 100% operational because our code is a little
different than official code but the issue has been tested with a very
recent nightly tar]
I use a user with "post-only" profile and see my list of ticket
then i click on advanced search and search on the ID of a ticket I am not
supposed to be allowed to see
Point 1) And I see the ticket in the result list (that can shock some
people but sometimes it is usefull to know that a ticket exist even if I
cannot see the content)
Point 2) the link on the ticket leads to a with page but the user can see
users /state /title/content and all follow up of the ticket using the
search (that I think is a little to much)
So I propose a small patch about point 2 (the point 1 is not an issue for
us but this point should be discuss by users to decide the "normal"
comportment of the tool, to correct the point 1 I suppose there must be
some work on the showTrackingList function)
-------------------------------------------------BEGIN Suggestion of Patch
---------------------------------------------------------------------
So in file Tracking_function.php
in function showJobShort($data,
$followups,$output_type=HTML_OUTPUT,$row_num=0) {
(near line
Original lines :
********************************************
if ($_SESSION["glpiactiveprofile"]["interface"]=="central"){
if (!$job->canShowTicket()) {
$nineth_column.=" ";
} else {
$nineth_column.="<a
href=\"".$CFG_GLPI["root_doc"]."/front/tracking.form.php?ID=".$data["ID"]."\"><strong>".$LANG["joblist"][13]."</strong></a> (".$job->numberOfFollowups().")";
}
}
else {
$nineth_column.="<a
href=\"".$CFG_GLPI["root_doc"]."/front/helpdesk.public.php?show=user&ID=".$data["ID"]."\">".$LANG["joblist"][13]."</a> (".$job->numberOfFollowups(haveRight("show_full_ticket","1")).")";
}
*************************************************
Becomes
if ($_SESSION["glpiactiveprofile"]["interface"]=="central"){
if (!$job->canShowTicket()) {
$nineth_column.=" ";
} else {
$nineth_column.="<a
href=\"".$CFG_GLPI["root_doc"]."/front/tracking.form.php?ID=".$data["ID"]."\"><strong>".$LANG["joblist"][13]."</strong></a> (".$job->numberOfFollowups().")";
}
}
else {
if (!$job->canShowTicket()) {
$nineth_column.=" ";
} else {
$nineth_column.="<a
href=\"".$CFG_GLPI["root_doc"]."/front/helpdesk.public.php?show=user&ID=".$data["ID"]."\">".$LANG["joblist"][13]."</a> (".$job->numberOfFollowups(haveRight("show_full_ticket","1")).")";
}
}
// We just Add -if (!$job->canShowTicket()) {- test for
non-central interface
// The same test should be done for the follow-up picture/data
************************************************
-------------------------------------------------END Suggestion of Patch
---------------------------------------------------------------------
Bonjour,
Nous travaillons sur la partie "ticket" de glpi et nous avons découvert un
petit truc:
[Pour information, nous avons fais une légère évolution graphique de GLPI,
dans le module suivi qui liste les tickets, Il y a le lien qui mène au
détail du ticket (aujourd'hui sur le libellé "Info" colonne de droite). Ce
lien est dans notre version sur le titre du ticket (ainsi la colonne qui
contenanit Info à maintenant disparues) et il y a plus de place pour les
titres. Le patch proposé ne sera donc peut être pas 100% opérationnel
(nous n'avons testé le patch que pour notre version). Par contre nous
avons reproduit le "problème" sur une version récente du Nigthly release]
Donc en travaillant avec un profile "post-only" , je vais dans le suivi
des tickets
Si je lance une recherche avancée et que je cherche par ID un ticket que
je ne suis pas censé voir,
Point 1) le ticket est quand même ramené par la méthode de recherche (cela
peut déranger certaines personnes mais cette fonctionnalité peut-être
pratique pour voir si un ticket existe même si l'on a pas les droits sur
ce ticket
Point 2) Grace à la sortie du ticket je peux voir le demandeur, la
personne attribué, la categorie, le titre ainsi que le contenu et les
suivis (grâce à la petite loupe verte)
Donc le patch proposé gère avant tout le point2 (le point 1 n'est pas un
problème pour nous mais peut être les différents utilisateurs de GLPI
devraient s'exprimer à ce propos pour savoir si l'outil doit ramener ou
non les tickets que l'utilisateur ne peut pas voir)
le patch sert a masquer le titre si l'utilisateur n'a pas le droit de voir
le ticket (il faudra repeter l'opération pour l'infobulle contenant les
suivis).
Pour corriger le point 1 je pense qu'il faut travailler sur la fonction
showTrackingList(.
Je ne repete pas le patch ici donc voir le patch ci-dessus
Cordialement
--
Guillaume Brusset
[EMAIL PROTECTED]
Envoyé par : [EMAIL PROTECTED]
31/12/2007 12:00
Veuillez répondre à
[email protected]
A
[email protected]
cc
Objet
Glpi-dev Digest, Vol 30, Issue 16
Send Glpi-dev mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://mail.gna.org/listinfo/glpi-dev
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Glpi-dev digest..."
Today's Topics:
1. Re: Optimisation RuleEngine (Julien Dombre)
2. Re: Optimisation RuleEngine (Remi Collet)
3. Re: Optimisation RuleEngine (Julien Dombre)
----- Message de Julien Dombre <[EMAIL PROTECTED]>
sur Sun, 30 Dec 2007 14:07:34 +0100 -----
Pour:
Liste de diffusion des developpeurs GLPI <[email protected]>
Objet:
Re: [Glpi-dev] Optimisation RuleEngine
Salut,
Je répond après la bataille mais bon. je commence juste a remettre le
nez dans ce qui a été fait sur la 0.71 au moment du debug de la 0.70
Si on charge les règles et qu'on les appliquent par la suite sur
plusieurs objets je ne vois pas pourquoi il les rechargerait vu qu'il y
a déjà un marqueur load ?
J'ai un peu du mal a comprendre en fait... J'ai sûrement loupé un truc.
++
Julien
Remi Collet a écrit :
> Remi Collet a écrit :
>
>> On peut aussi jouer avec un "singleton" mais ça complique
l'utilisation.
>>
>
> Voir : https://dev.indepnet.net:8080/glpi/changeset/6200
>
> Avec cette solution, le chargement d'un moteur de règle ne se fera
> qu'une seule fois dans la vie d'un script.
>
> A tester, en particulier sous PHP 4, mais je pense que c'est bon (je
> suis parti d'un "Design Pattern" pour PHP 4).
>
> A+
>
>
>
> _______________________________________________
> Glpi-dev mailing list
> [email protected]
> https://mail.gna.org/listinfo/glpi-dev
>
----- Message de Remi Collet <[EMAIL PROTECTED]> sur Sun, 30 Dec
2007 16:37:30 +0100 -----
Pour:
Liste de diffusion des developpeurs GLPI <[email protected]>
Objet:
Re: [Glpi-dev] Optimisation RuleEngine
Julien Dombre a écrit :
> Si on charge les règles et qu'on les appliquent par la suite sur
> plusieurs objets je ne vois pas pourquoi il les rechargerait vu qu'il y
> a déjà un marqueur load ?
Oui, mais pas toujours.
Le marqueur "load" évite les chargements multiples dans un même objet.
Pas exemple : lorsqu'on rejoue le dictionnaire des softs, la classe
RoleCollectionDictionnarySoftwareCollection n'est instanciée qu'une
fois, mais la classe DictionnaryManufacturerCollection est instanciée
pour chaque logiciel (processManufacturerName), ce qui provoque à chaque
fois le chargement du jeu de règles.
En particulier aussi, lors de la synchro OCS, la fonction
externalImportDropdown instancie à chaque fois le moteur de règle du
dictionnaire correspondant à l'objet en cours de traitement.
Donc le singleton permet un chargement unique de chaque dico au cours de
l'exécution d'un script.
Voili, voila.
A+
----- Message de Julien Dombre <[EMAIL PROTECTED]>
sur Sun, 30 Dec 2007 16:59:53 +0100 -----
Pour:
Liste de diffusion des developpeurs GLPI <[email protected]>
Objet:
Re: [Glpi-dev] Optimisation RuleEngine
Remi Collet a écrit :
> Julien Dombre a écrit :
>
>> Si on charge les règles et qu'on les appliquent par la suite sur
>> plusieurs objets je ne vois pas pourquoi il les rechargerait vu qu'il y
>> a déjà un marqueur load ?
>>
>
> Oui, mais pas toujours.
> Le marqueur "load" évite les chargements multiples dans un même objet.
>
> Pas exemple : lorsqu'on rejoue le dictionnaire des softs, la classe
> RoleCollectionDictionnarySoftwareCollection n'est instanciée qu'une
> fois, mais la classe DictionnaryManufacturerCollection est instanciée
> pour chaque logiciel (processManufacturerName), ce qui provoque à chaque
> fois le chargement du jeu de règles.
>
Ok ca me semble effectivement une bonne chose.
Je n'avais pas percu ce cas de figure.
++
Julien
_______________________________________________
Glpi-dev mailing list
[email protected]
https://mail.gna.org/listinfo/glpi-dev
*******************************************************************
Ce message et les pieces qui y sont eventuellement jointes sont
exclusivement transmis a l'intention des personnes physiques ou morales
auxquelles ils sont destines.
Si vous avez recu ce message par erreur, merci d'en avertir immediatement
Mazars par telephone ou par courrier electronique de retour a l'expediteur
et de supprimer toute copie de ce message.
Par ailleurs, il vous est notifie que toute divulgation, reproduction,
distribution ou utilisation quelconque de tout ou partie de ce message (y
compris de ses eventuelles pieces jointes) et des informations qui y sont
contenues est interdite.
Internet ne permettant pas d'assurer l'integrite de ce message, Mazars et
l'expediteur declinent toute responsabilite au cas ou il aurait ete
intercepte ou modifie par quiconque.
This message and any possible attachments are transmitted for the
exclusive use of the intended recipient(s).
Should you receive this message by mistake, please notify Mazars or the
sender at once by telephone or return e-mail and delete it from your
system.
Moreover, any form of reproduction dissemination, copying, disclosure,
modification, distribution and/or use of this message - or part of its
contents, as well as its possible attachments by any unauthorized person
or legal entity, is strictly prohibited.
The nature of the Internet means that the integrity of this message cannot
be guaranteed. Mazars and the sender therefore disclaim any liability
whatsoever in the event of this message having been intercepted and/or
altered.
********************************************************************
This message has been scanned for viruses by BlackSpider MailControl -
www.blackspider.com
_______________________________________________
Glpi-dev mailing list
[email protected]
https://mail.gna.org/listinfo/glpi-dev
