2012/12/29 Remi Collet <[email protected]>
> From the "client" point (ITIL), the status stay "in progress" (client
> really don't care how you manage internal stuff). And SLA, or resolution
> time, don't have to change because of any external consultant.
>
> You should assign the ticket to the consultant (supplier) to track such
> process.
As far as I was talking to my boss, he told me:
The requirement is not for the (end) clients, it is for our help desk
team.
When a ticket is created with the status "Waiting for external
consultant"
(supplier if you wish), there is a logistic procedure that has to be
made,
therefore, for us it's important to recognize/distinguish this kind of
tickets
from the other ones.
Now, I'm not really interested in changing the route-map of GLPI
because my
own requirements, but after reading the answer about the "templates
engine"
and this specific thread, I'm starting to feel that the GLPI
architecture is being
defined thinking of "just one way" or "the official way".
I mean, when you people, say things like:
- "User shouldn't use/see/think like that..."
- "Templates engine it's not the main goal of the project, for CMS of
course you
must have a custom theme, for GLPI it's very less important"
I think you are assuming too much about the world out there. If
something I have
learned about free software projects since 1993, it's that for any
software of any
kind, customization is always needed.
I want to add that I'm free software developer currently too
(http://www.maefloresta.com), so, I'm not writing this mail as the
classic user who
likes to complain, but as someone who shares your journey in some way.
Now, GLPI plugin's are a great resource to adjust the software for
special needs,
but as part of the core, I think that GLPI should incorporate some
features to facilitate
the customization process. For example, the addition/edition of ticket
states should
be natural/easier, not because I need it, but because it's very
possible that a lot of
people want to use this feature.
Of course, you can say: "Oh! That's not ITIL, that's not part of the
official procedure, etc"
but the truth is every company has its own requirements or "culture" if
you wish, and in the
case of GLPI, a high level of flexibility is still expected/required.
Why I'm saying this? I have to replace the implementation of "Aranda"
(http://www.arandasoft.com/) in an important government institution of
my country
with GLPI, and as far as I was studying the GLPI source code I already
realized that
I'll have to make several hacks to cover all the requirements my Boss
is asking me.
I would love to tell him things like: "users don't care about that",
"that's not important"
but the real world is not "so ITIL" as we would wish.
From my point of view, GLPI should be the application killer of Aranda,
but not as a hard
copy of it, but as solution that can be customized in an easy way to
replace it.
I'll expect to share with you all the changes/patches/plugins or
whatever I have to do to
achieve my goal, and of course, you'll decide what you want to include
or not for the future
versions of GLPI, finally it's your decision.
The only thing I really care about it, it's that reconsider your
politics about what requirements
should be included as part of the main core of GLPI.
Thank you for reading this long and boring message ;)
--
============================
Gustav Gonzalez
[email protected]
============================
_______________________________________________
Glpi-dev mailing list
[email protected]
https://mail.gna.org/listinfo/glpi-dev
