Feature Request: Multi-select support for GLPI object fields in Forms

[SDenbow]

Summary

Enable selection of multiple existing GLPI objects (e.g., Suppliers, Locations, Assets, dropdown values) within a single Form field, with proper linkage to the resulting ticket.

Context

GLPI Forms are a powerful way to standardize user input and drive structured ticket creation. However, currently, fields that reference existing GLPI objects only support single selection.

In many real-world scenarios, a request naturally involves multiple related objects, which cannot be represented accurately with the current limitation.

Use Cases

1. Service Disruption / ISP Outage
   Suppliers are used to represent ISPs
   A disruption can affect multiple ISPs at once
   Form currently allows only one Supplier to be selected
2. Multi-Location Incidents
   An issue (network, power, application) impacts multiple sites
   Locations are already defined in GLPI
   Only one Location can be selected in the form
3. Asset-Related Requests
   A user reports an issue affecting multiple computers or devices
   Assets exist in GLPI inventory
   Form cannot associate more than one asset
4. Client / LOB Impact
   Multiple clients or lines of business are affected by a single issue
   Custom dropdowns are used to represent these entities
   Multi-selection is not possible
   **
   Current Limitation**

Fields in Forms that reference:

Core objects (Suppliers, Locations, Assets)
Existing dropdown fields

…only allow single-value selection.

Workaround (and its drawbacks)

To handle multi-selection, administrators must:

Create a separate custom dropdown field inside the form
Duplicate values from the original GLPI object list

This introduces several issues:

Data Duplication
Same dataset maintained in multiple places
Risk of divergence over time
Increased Maintenance
Updates must be manually synchronized (additions, renames, removals)
Loss of Object Relationships
Tickets are no longer linked to the original GLPI objects
Impacts reporting, automation, and consistency
User Confusion
Multiple sources of truth for the same data
Increased chance of incorrect or outdated selections

Proposed Enhancement

Allow Form fields referencing existing GLPI objects to support multi-selection.

This could apply to:

Suppliers
Locations
Assets (Computers, etc.)
Existing dropdown fields

Expected Behavior

Ability to select multiple values within a single field (e.g., multi-select dropdown, checkbox list)
Selected objects are:
Properly linked to the resulting ticket
Stored using existing GLPI relationships (no duplication)
Backward compatibility with existing forms (single-select remains supported)

Design Considerations (Non-Prescriptive)

Could be implemented as an optional field configuration (single vs multi-select)
Should reuse existing object references rather than introducing new data structures
UI/UX should remain consistent with existing GLPI selection components where possible

Benefits

Preserves data integrity by avoiding duplication
Reduces administrative overhead
Enables more accurate modeling of real-world scenarios
Improves reporting and automation capabilities
Aligns Forms behavior with GLPI’s existing ability to associate multiple objects with tickets

Additional Note

This limitation frequently leads administrators to recreate existing GLPI data structures within Forms, which works against the goal of centralized data management.

Supporting multi-select would significantly improve both usability and long-term maintainability of Form configurations.

[SDenbow]

Follow-up after digging into GLPI 11.0.6 source:

I investigated this further because this capability is important for our deployment, and I found something that may help clarify scope.

QuestionTypeItem appears to currently be implemented as a strictly single-select question type:

• Uses items_id rather than an array of IDs
• Uses default_items_id
• Default value handling casts to a single integer
• End-user/admin templates render a single dropdown

However, Forms already appears to support multi-select patterns elsewhere:

• is_multiple_actors
• is_multiple_dropdown
• is_multiple_devices

Those question types already have:

• multiple selection UI
• config flags
• storage/handling patterns
• condition handling support

Based on this, this seems less like a new capability request and more like extending QuestionTypeItem with the same multi-select pattern already used by other question types.

Potential implementation direction:

• Add is_multiple_items
• Add “Allow multiple objects” configuration
• Support items_id[]
• Update formatting/rendering/condition handling for arrays

For our use case, forms frequently need to associate multiple existing GLPI objects (suppliers, locations, assets, client/LOB values, etc.) to preserve relationships and reporting accuracy.

Can someone confirm whether this approach aligns with the intended architecture, or if there are constraints that make QuestionTypeItem intentionally single-select?