Feedback tests on Plugin Development - Entity Management

[ltfarm]

Hi, how are you?

Thank you for the modifications and updates, especially for the splendid work.

We still found some issues during our tests. To better illustrate, I will first present an example of our structure.

Context:

We have a shared service desk that is not limited to ICT but covers various sectors of the organization, such as finance, general services, inventory, information technology, human resources, among others.

GLPI allows better management when working by entity. For example, if a ticket is 'new,' all groups can see it, but if we divide it by entity, this does not happen. Additionally, the list of technicians presented does not cover only the queue in question, among other factors. This points us to a great opportunity and benefit of this plugin for the ICT community.

Thus, our structure has several entities and sub-entities, in some cases one more level of entity. In some examples, there are groups in the entities, while in others there are not.

The profiles are applied in the child entity. For example, each entity has a specific profile to customize permissions, such as the Support Directorate, which cannot view tickets or other objects from other entities, as their permissions only work in the entity in question.

The image shows the most visual scenario.

Problems:

The organization of parent/child entities can cause confusion with child entities. For example, we noticed that the organization is done in such a way that, first, we present all the parent lists, and then the child lists. This way, people may incorrectly transfer a ticket to the parent entity instead of the child entity. It would be interesting to present the PARENT entities, such as IT, HR, Financial. If there are sub-entities within them, a new field with the children being presented would allow a sequence and precision in the selection by the technician.

When transferring a ticket from the "support" entity to "recruitment," group "training," the group changes, but the entity remains "support." In other words, the entity is not changing, based on the tests we performed.

Would it be possible to reset the ticket category when transferring? You could test the "behaviors" plugin that allows you to block closing tickets without a category. This way, the technician is forced to insert a category and, also in the plugin, can choose when to move the ticket, what the new status we want to define. This way, you would not need to worry about these and other movement functions.

Add a shortcut for transfer on the transfer screen, thus reducing the number of clicks for the user.

Best regards,

[YannickComba]

Hello,

Thanks for your feedback and your detailled explanation, I've reproduced your environment and I've done several test on it :

• The organization of parent/child entities can cause confusion with child entities. For example, we noticed that the organization is done in such a way that, first, we present all the parent lists, and then the child lists. This way, people may incorrectly transfer a ticket to the parent entity instead of the child entity. It would be interesting to present the PARENT entities, such as IT, HR, Financial. If there are sub-entities within them, a new field with the children being presented would allow a sequence and precision in the selection by the technician.

This will be implemented later due to time consuming, we first need to decide how it will look.

• When transferring a ticket from the "support" entity to "recruitment," group "training," the group changes, but the entity remains "support." In other words, the entity is not changing, based on the tests we performed.

I tried with your environment and I didn't have this problem, did you unistall then re-install the plugin or did you upgrade it ? In case you upgrade it, could you try to desinstall and reinstall it ?

• Would it be possible to reset the ticket category when transferring? You could test the "behaviors" plugin that allows you to block closing tickets without a category. This way, the technician is forced to insert a category and, also in the plugin, can choose when to move the ticket, what the new status we want to define. This way, you would not need to worry about these and other movement functions.

In the version 1.1.1, it will be implemented in administration > entity and you will be able to chose if category is reset or not.

• Add a shortcut for transfer on the transfer screen, thus reducing the number of clicks for the user.

This might be implemented in a later version.

Regards.

[YannickComba]

Hello,

For your following problem :

• When transferring a ticket from the "support" entity to "recruitment," group "training," the group changes, but the entity remains "support." In other words, the entity is not changing, based on the tests we performed.

In Administration > Profile > YourProfile > Assistance > Ticket : Update must be checked. It might be the reason why your entity didn't swap at this time.

In the next version, I'll add an error message in this forgotten case.

Regards.

[bolivarf]

Hello, A question will be very complicated to add in the Default Configuration category in Entity the option to Ask For and in this way when the ticket is transferred you can choose a category of the destination entity. Regards.

[YannickComba]

Hello, A question will be very complicated to add in the Default Configuration category in Entity the option to Ask For and in this way when the ticket is transferred you can choose a category of the destination entity. Regards.

Hello,

If I understood correctly, you wish that the technician who send the ticket can chose the category of destination entity that's it ? If so, it's not planned to add this feature because if a ticket is send to another entity, it's because the technician has neither the right nor the visibility on said entity. Allowing him to see other categories would be inconsistent with the plugin rules

Regards

[albonneauEDNA]

If the technicien ( With a recursive profil ) is transferring a ticket from a parent entity to one of it's child it would show the sub-category and work right ?

This plugin could be a lifesaver for my company. I'm working on some proof-of-concept with GLPI where end-users could open a ticket on GLPI with a form in the Root Entity and get this tickets to be automatically transfered to the right sub-entities based on the category of incident/demand.

This would allow our end-user to send tickets to multiple departments without having to use more than one profil and at the same time, allow our departments to use GLPI with another profile in their own sub entities to track works with their colleagues.

Do you think it would be too much work, adding an automatic check of the category on ticket creation and send it to the entities where this category was created ?

[ltfarm]

Hello @albonneauEDNA

Below is a configuration for this case, as I believe it may not need to be implemented in the plugin, if I have understood correctly.

You can add users at the root to open requests, for example, using the formcreator plugin. After the ticket is generated, you configure business rules to direct this request to the correct entity, as well as parameterizing other existing metadata.

For the user, it remains transparent.

I observe this plugin more for post-creation of the ticket, where the technician needs to move it.

Additionally, in this configuration, you won't need to have multiple profiles for the end user. In the organization where I work, we configure it this way.

[albonneauEDNA]

I know I could use the FormCreator plugins for this use case it work well and might implement this solution for now.

But it's adding more workload to create a form and is also more technical and less simple for certain user ( let's say if the HR department need a new form for some cases, I don't think they would be able to be autonomous, ) not that much of an issue for me to do it for them but having the ticket auto transferred is a nice QoL ;)

[departement-maine-et-loire]

Hello,

I agree with @ltfarm 's answer: it's not up to the TransfertTicketEntity plugin to meet this type of need when creating a ticket, which is already handled by FormCreator: that's what we do, and it works very well.

Note that, as GLPI admins, we take charge of form creation (no delegation is given for creation). Creating a form is a burden, but it saves time later on.

In addition, I would be grateful if you could open a new issue for any request that is not related to the open issue.

Regards