FIX / Restore the "include sub-groups' members" toggle

[Mary-Clb]

• I have read the CONTRIBUTING document.
• I have performed a self-review of my code.
• I have added tests that prove my fix is effective or that my feature works.
• This change requires a documentation update.

Description

• It fixes !45960
• When a user belongs to both a group and its sub-group, that user is shown twice (once per real membership). This is intentional, per the PR Groups UI Twig #16721 review discussion itself: each row is a genuine, distinct glpi_groups_users record, labelled by its own "Group" column. This PR does not change that behavior — clearDuplicatedGroupData() stays disabled, as decided at the time.
  However, for the sake of clarity on the end-user side, it was decided to restore a Yes/No toggle so admins can choose for themselves whether they want that aggregated, sub-groups-included view at all, rather than always having it forced on them. Care was taken to preserve any active column filter (Manager, Dynamic, Delegatee).

Screenshots :

[stonebuzz]

The UI bothers me a little.

Having the filter displayed here, especially across two lines, doesn’t feel very clean or consistent from a UI perspective.

I would suggest moving the filter to this location instead (IMHO):

This would probably require adapting/improving glpi/templates/components/datatable.html.twig to support the configuration of additional filters that can be handled directly by the datatable.

It will require a bit of work, but I think it could be a worthwhile improvement, as this mechanism could potentially be reused in other contexts as well.

What do you think, @cconard96 ?

[cconard96]

What do you think, @cconard96 ?

IMO The filters make more sense above or inline with the pager text ("Showing 1 to X of X rows"), but certainly not above the form to add a user to the group. I also don't really like the idea of having some filters always showing and others hidden behind a button, but datatable only supports filters directly tied to specific columns so not much we can do without redoing all of it.

At the very least, I suggest placing the filter after the "add user" form and making sure the form, recursive filter, and results are visually separated with a horizontal rule or border.

[orthagh]

close/reopen to force snyk to give details about its fail.

[Mary-Clb]

I moved the toggle below the "add user" form, added an <hr> separator between the form and the toggle, and contrained its width so the label + select stay on a single line, right-aligned near the pager. the adresses @cconard96 minimum request without touching any shared template.

Proposed follow-up for the datable integration - @stonebuzz 's suggestion - rather than a full filter-engine rework, add a lightweight, reusable slot to templates/components/datatable.html.twigfor caller-provided filter controls, rendered in the table toolbar right after the pager:

{% if additional_filters is defined and additional_filters is not empty %} <div class="d-flex flex-wrap align-items-end justify-content-end gap-2 mb-2 border-bottom pb-2"> {{ additional_filters|raw }} </div> {% endif %}

The caller just builds the control HTML and passes in it :

TemplateRenderer::getInstance()->display('components/datatable.html.twig', [ // ... 'additional_filters' => $tree_toggle_html, ]);

This keeps the toggle visually inside the datatable, aligned with the pager and separated from the results, and the slot can be reused by any other list that needs a non-column filter. A fully structured config ({name, type, label, options}) that the datatable turns into a reloadTabcall itself is doable later but is a lot more surface for this bugfix.
Do you want the additional_filters slot in this PR ?

I ping @AdrienClairembault to have his opinion.

[trasher]

LGTM from a code point of view