GLPI is able but in limited degree (using link ticket function or using tag plugin) We was waiting for Project feature but we are disapointed. In actual state is not useful as it could be.

We need this feature to measure ROI. We need know history to do better in the future. We need to know impacts to evaluate projects.

Your use isn`t just history and you can have expense metrics. You need to measure and to record informations needed for expense metrics. From history you can learn to do thing better and find unknown/hidden informations.

We start using GLPI form same use -only evidence request for repair or help. But after some time we found that GLPI can help us to measure, to find hidden informations, to improve our work, to do our work easily,.....

We start using asset management and other features. Wwe start to learn how can GLPI help to us, but now we are in state that we found limitations of GLPI.

Look at my other requests. We need this features to work effectively.

http://glpi.userecho.com/topics/100-plan-ticket-not-only-ticket-tasks/

http://glpi.userecho.com/topics/129-regular-technical-inspection-on-items/

http://glpi.userecho.com/topics/513-option-to-assign-entities-to-groups-or-add-field-location-to-entities-and-search-tickets-by-this/

I have many other ideas to improve GLPI, this four ideas is most essential for us. I have some ideas from other people which contact me about installing and using GLPI. GLPI is great SW but not perfect.

I wrote long review (8 chapters),

https://www.linuxexpres.cz/software/glpi-kvalitny-open-source-helpdesk-a-sprava-it-zariadeni?highlightWords=glpi

I`d like to write a book about GLPI.

You don`t understand me.

I want to assign ticket to project directly, not to task. Now it`s possible assign ticktet to project, but only using project task and this is a problem. It`s complicated and I can assign only opened tickets.

I give you example.

We have project named "Migration from MS Office to LibreOffice"

We have project team which tested migration, prepared methodology,.... and finaly created manuals for technicians

Technicians performed migration.

Now users works with LibreOffice and they founding bugs or things that not working.

What they will do? They will create tickets.

We need assign these ticket to project to see how many tickets generates this migration/this project and want to see types of these ticket. Project team gets these informations and adjust needed things in project,..... At the end we want to evaluate success of project.

Today I can`t do this simple way. I can`t assign ticket to project easily. I can`t assign resolved ticket to project,...

I can`t evaluate project. In this state the project is independent/autonomous feature without good relation to tickets.

I don`t want avoid tasks. Tasks is good feature, but in some cases, task is unnecessary(unnecessary bureaucracy). We want to choose - plan task or plan ticket.

Your proposal is not good because not all use tasks and solutions. And our problem is not solutions an closing tickets, our problem is only how to simple plan tickets(plan work for technicians).

We have many tickets where we no need to use tasks. We need simple way to work with that tickets. Our service team need that to work effectively.

I don`t know the project plugin, too. I tested this plugin only for while by suggestion JBaily.

I mean Project feature in GLPI.

We want tickets generated by project link to this project. We need check how many tickets generate project(kind of tickets and other thing to evaluate project) Now we can`t do this simple way.

I can link ticket only this way -In selected project i must create project task and in project task I can add ticket.

It is too complicated way.

Good way is

1.in selected project add entry Ticket where I can add/link tickets(like adding items to projects or adding changes to project)

2.using massive action - mark tickets and link selected tickets to project using massive action

3.open ticket and link this ticket to project

As I wrote - Project is good feature but in actual state is not useful as it could be.

Reccurent ticket is not good for this and there is no link between ticket and inventory item. It is good to have timeline log in item history about regular inspections. Set regular technical inspection on items group(selected items) using (maybe) massive action,.... This I can`t do with reccurent tickets.

No. We don`t wont inventory items.

We need send technician to service customers printer every 6 months and we want that GLPI create ticket two weeks before date of service. When technician resolve(or close) created ticket in GLPI, start new 6 month period.

We need do this with other items in inventory, too.

It`s simple. We have many simple tickets that we no need to divide to tasks.

Example. We have ticket "jammed paper in printer" and we no need to do something with this ticket. Only assign and plan this ticket.

Now we can`t do this. We have three choices

1.create task and plan this task

2.use external program for planing tickets without tasks

3.not using planning.

Any choice isn`t good.