N°903 - Portal : Search / Filter on Browse mode mosaic

[Sbleut]

N°903 - Portal : Search / Filter on Browse mode mosaic

Allow users to filter mosaic items dynamically while typing. Search operates case-insensitively on name, description, and tooltip title. Reset filter automatically when navigating between mosaic levels.

Base information

Question	Answer
Related to a SourceForge thread / Another PR / Combodo ticket? ****	**N°903 - Portal : Search / Filter on Browse mode mosaic //**R-044277 - Proposition PR : Portail Mosaic Filter
Type of change?	Enhancement

Objective (enhancement)

In the Browse Brick of the portal (mosaic mode), when many service families or services are displayed, it becomes difficult for end users to quickly find the item they are looking for.

Proposed solution (enhancement)

Add a dynamic client-side search field above the mosaic content.

Filter behavior :

• Adds a live search field above the mosaic content
• Filters items dynamically while the user types
• Performs case-insensitive matching
• Searches in:
  • Mosaic item name
  • Description
  • Tooltip title (data-original-title)
• Does not require any page reload
• Has no backend impact
• Automatically resets when navigating between mosaic levels

Tests

This change impacts the portal mosaic UI only (Twig + client-side JavaScript).

No PHP unit tests were added because the feature does not introduce
backend logic, API changes, or data model changes.

The behavior was validated manually in the portal by testing:

• live filtering while typing
• case-insensitive matching
• filtering on name, description and tooltip title
• automatic reset when navigating between mosaic levels

Checklist before requesting a review

• I have performed a self-review of my code
• I have tested all changes I made on an iTop instance
• I have added a unit test, otherwise I have explained why I couldn't
• Is the PR clear and detailed enough so anyone can understand digging in the code?

Checklist of things to do before PR is ready to merge

Things that needs to be done in the PR before it can be considered as ready to be merged

• Changes requested in the review

[Molkobain]

Hello @Sbleut thanks for the PR!

Could provide screenshots of the UI without and with filtering so we can see how the items are displayed if:

• No itme smatch
• Items from different levels match

[Sbleut]

No item Match :

Subcategory level matching on "windows" :

Service level matching on "windows" :

[Molkobain]

Thanks for the screenshots @Sbleut , it is just missing the "Items from different levels match" use case.

In list and tree mode, you can filter all levels at once. If we add filtering to the mosaic view as well, it must do the same, not a 1-level filtering only. That's why we didn't made it in the first place, as we didn't really now how to display it.

So in order to move forward with considering the PR, we need to see an example where you have items matching the filter in the 3 levels "Service Family", "Service" and "Service Subcategory" so we can see how it will display when displaying matches for different levels at the same time. :)

Or does the filtering only works for the level currently displayed?

[Sbleut]

My bad, currently the filtering only works for the level currently displayed.

It appears it would be quite complicated to keep Mosaïc display and showing all the levels were there is a match. It would involve ajax call and some UI reorganisation.

For now all the needs we answer only care about the current level but i understand if doesn't match your will to keep the same functionality for each mode.

[Molkobain]

[...] In list and tree mode, you can filter all levels at once. If we add filtering to the mosaic view as well, it must do the same, not a 1-level filtering only. That's why we didn't made it in the first place, as we didn't really now how to display it. [...]

Thanks for the feedback.

Indeed, as I said in my previous message, that's why we didn't do it initially, because we wanted to address this issue globally the same way it's done on other display modes.

POs will decide if we should proceed with this, but from a technical point of view I would not accept the proposition as-is.

[jf-cbd]

Hello @Sbleut, thank you for your PR. We'll work on the related ticket in sprint for version 3.4 (starting in September), since we need to think about the best way to code this feature. When we'll work on it, we'll get back to you at this moment.