GeezerVison

Hi @JeremieMercier

I am questioning the plugin's ability to reconcile the correct container during API calls, an issue we have encountered in the past. For example, when updating a ticket and including the "fields" in the payload, could you verify this point?

Hi @stonebuzz,

I retrieve the block row ID like this:

Then, I update the field using the following method:

So I haven’t encountered any issue with the API — unless I misunderstood how you're updating the fields via the API?

It is also possible to update fields from the fields plugin during ticket update.

PUT {{URL_GLPI}} /Ticket/5

Yes, it works

Just include the block ID in the field name, like:
plugin_fields_15_bloconechamponefield

Hello, do you have time to review the PR ?

I applied the changes for PHPStan 🤞

I don't understand @trasher

With php 7.4 :

A syntax error, it was slipped in after applying the suggestion 😅

Are we good this time ? 😅🤞

Hi, what's the next step ?

Hi @JeremieMercier

The feature you are proposing is substantial and introduces significant changes. To ensure its smooth integration and functionality, we must be extremely vigilant. This means we need to "lock down" our testing to guarantee that everything works as expected.

It is important to acknowledge that the plugin is already complex to maintain, especially with the new features introduced in GLPI. Given this complexity, we must approach any additional features with caution to ensure they do not further complicate maintenance and support.

To ensure the proper functioning of this PR, here is a concise list of unit tests that should be added:

Unit Tests for findContainers

1. Retrieve Containers for Specific Itemtype and Entity

   • Verify that findContainers returns the correct containers for a given itemtype and entity.

2. Retrieve Containers with Subtype

   • Verify that findContainers returns the correct containers when a subtype is specified.

3. Retrieve Containers with Recursive Entity

   • Verify that findContainers considers recursive entities.

Unit Tests for Hooks

4. preItemAdd with Multiple Containers

   • Verify that the preItemAdd hook correctly handles data for multiple containers.

5. postItemAdd with Multiple Containers

   • Verify that the postItemAdd hook correctly updates field values for multiple containers.

6. preItemUpdate with Multiple Containers

   • Verify that the preItemUpdate hook correctly handles data for multiple containers during item update.

Unit Tests for populateData

7. populateData with Prefix

   • Verify that populateData correctly extracts field values by removing the prefix.

8. populateData with Multiple Selection Fields

   • Verify that populateData correctly handles fields allowing multiple selections.

Unit Tests for showForTab

9. showForTab with Multiple Containers

   • Verify that showForTab correctly displays containers for a given item.

10. showForTab with Insufficient Rights

    • Verify that showForTab returns nothing if the user does not have sufficient rights on the containers.

Unit Tests for API

11. Ticket input update

12. Container update

Unit Tests for rights

Hi @stonebuzz Thanks for the message

I fully understand the concerns and the importance of thorough testing.
I'm currently working on implementing the required tests and will make sure all the listed cases are properly covered.

While working on the tests already partially in place, I’ve been able to identify and fix some issues especially related to "dropdown" field handling and container restriction management.

I’ll keep updating here as I progress.

Hi, @JeremieMercier.
What tool you are using to send HTTP requests?
I'm newby in WEB development so I'm not entirely shure what tool is that.
Thank you :)

Edit: I've done some research and found Postman, as a tool to send HTTP requests and creating API tests

I’ve added all the requested unit tests (except the API ones):

• findContainers : basic cases, sub-types, entity recursion
• Hooks: preItem, postItemAdd, preItemUpdate with multiple containers
• populateData: prefix handling and multi-selection fields
• showForTab: displaying multiple containers and checking rights

Please note I’m not a testing expert, so the tests may not follow every usual best practice. Feel free to share any feedback so I can improve.

The API tests still need to be written by whoever is willing to tackle them.

Hello,
Tank you very much @JeremieMercier for this work. That's a realy needed feat for us !
Any followup of this PR ?
Best regards

Hello, Tank you very much @JeremieMercier for this work. That's a realy needed feat for us ! Any followup of this PR ? Best regards

Hello @CorentinS6, From my side everything seems good, it remains to be seen if a developer of the project can finalize the tests

And code generated by AI ?

And code generated by AI ?

Hello, All the logic is 100% mine, however for the tests, it's another story, I used AI to learn and understand the use of the tests in addition to videos like this one from Grafikart, but as I said, I'm not an expert..., the tests can also be redone by a more competent person if necessary knowing that basically, there were no tests set up on the plugin.

@stonebuzz , is this work good enough for the merge now?

This will be very useful, now I can only add one block to all entities, I need one per entity and this seems to solve the problem, is there something I can help with?

Hi,
I have some needs for that type of thing.
Like i have an entity that needs different informations on tickets than the other, but even tho my fields are created seperately on the entities, i'm blocked because it'es for the same "type".
Is there a way to do this in glpi 11 ?
Thank you

I originally opened this PR because it was an internal feature request for how we use the GLPI plugin. In the end, we managed without it, so I kind of let it drop especially with the commit lag and conflicts to deal with.

Anyway, I've decided to pick it back up: even though we don't need the feature ourselves anymore, it could still be useful to others since it's quite heavily requested ^^

hi @Rom1-B, and now ?

I’ll put the PR back into draft status, as it is not yet complete (see conflicts) and has not been updated for some time.