Skip to content

feat(table): support embeddable question types inside table columns - #45

Closed
alisher372 wants to merge 5 commits into
pluginsGLPI:mainfrom
alisher372:main
Closed

feat(table): support embeddable question types inside table columns#45
alisher372 wants to merge 5 commits into
pluginsGLPI:mainfrom
alisher372:main

Conversation

@alisher372

Copy link
Copy Markdown

Summary

Add support for embeddable question types inside table question columns.

Instead of knowing about specific plugins, the table question now delegates rendering to any question type implementing the new embeddable interface.

What is implemented

  • support for embeddable question types;
  • dynamic column configuration loading;
  • embedded administration rendering;
  • embedded end-user rendering;
  • server-side rendering for dynamically added table rows;
  • validation and preparation of embedded question extra data.

Why server-side row rendering?

Originally, additional table rows were created entirely in JavaScript.

This approach worked for built-in question types because their client-side configuration was sufficient to recreate the controls.

With embeddable question types, this is no longer enough. Embedded question types are responsible for rendering and initializing their own controls, which may include server-generated markup, unique identifiers and initialization logic.

To keep this responsibility inside each question type and avoid duplicating rendering logic in JavaScript, newly added rows are now rendered on demand by the server through a dedicated controller. The controller simply exposes the existing row rendering logic already used for the initial table rendering, ensuring that dynamically added rows behave exactly like the initially rendered ones.

Motivation

The table question previously only supported built-in question types.

With this change, any question type implementing the embeddable interface can be used inside a table without introducing plugin-specific rendering logic into Advanced Forms.

Backward compatibility

Existing built-in question types continue to work exactly as before.

Plugins that do not implement the embeddable interface are unaffected.

Related

Depends on:

Example implementation:

## Summary

Add support for embeddable question types inside table question columns.

Instead of knowing about specific plugins, the table question now delegates rendering to any question type implementing the new embeddable interface.

## What is implemented

- support for embeddable question types;
- dynamic column configuration loading;
- embedded administration rendering;
- embedded end-user rendering;
- server-side rendering for dynamically added table rows;
- validation and preparation of embedded question extra data.

## Why server-side row rendering?

Originally, additional table rows were created entirely in JavaScript.

This approach worked for built-in question types because their client-side configuration was sufficient to recreate the controls.

With embeddable question types, this is no longer enough. Embedded question types are responsible for rendering and initializing their own controls, which may include server-generated markup, unique identifiers and initialization logic.

To keep this responsibility inside each question type and avoid duplicating rendering logic in JavaScript, newly added rows are now rendered on demand by the server through a dedicated controller. The controller simply exposes the existing row rendering logic already used for the initial table rendering, ensuring that dynamically added rows behave exactly like the initially rendered ones.

## Motivation

The table question previously only supported built-in question types.

With this change, any question type implementing the embeddable interface can be used inside a table without introducing plugin-specific rendering logic into Advanced Forms.

## Backward compatibility

Existing built-in question types continue to work exactly as before.

Plugins that do not implement the embeddable interface are unaffected.

## Related

Depends on:

- GLPI Core PR: glpi-project/glpi#25065

Example implementation:

- Fields PR: pluginsGLPI/fields#1235
When using GLPI Custom Dropdowns inside table questions, all dropdown definitions display the same combined list of values.

This happens because all custom dropdowns use the same database table (`glpi_dropdowns_dropdowns`), but the current implementation does not apply the system criteria that distinguish each dropdown definition.

## Solution

This change updates the table question implementation to correctly filter Custom Dropdown values by applying the item's `getSystemSQLCriteria()` when:

- loading dropdown options;
- resolving stored values.

As a result, each Custom Dropdown now displays only the values that belong to its own definition.

Before

<img width="290" height="339" alt="Снимок экрана 2026-07-21 143100" src="https://github.com/user-attachments/assets/fc015b93-514c-4d16-84e2-0909d5e6e3a1" />
<img width="211" height="335" alt="Снимок экрана 2026-07-21 143054" src="https://github.com/user-attachments/assets/04f9cd49-92bb-42f2-97ed-4e8b675d4367" />

After

<img width="226" height="238" alt="Screenshot 2026-07-31 163806" src="https://github.com/user-attachments/assets/7da6c20d-1124-44b2-a6b1-5f69ef69c6e1" />
<img width="250" height="266" alt="Screenshot 2026-07-31 163809" src="https://github.com/user-attachments/assets/56dcdc8f-2074-4845-aa97-d704016fdd77" />
When using GLPI Custom Dropdowns inside table questions, all dropdown definitions display the same combined list of values.

This happens because all custom dropdowns use the same database table (`glpi_dropdowns_dropdowns`), but the current implementation does not apply the system criteria that distinguish each dropdown definition.

## Solution

This change updates the table question implementation to correctly filter Custom Dropdown values by applying the item's `getSystemSQLCriteria()` when:

- loading dropdown options;
- resolving stored values.

As a result, each Custom Dropdown now displays only the values that belong to its own definition.

Before

<img width="290" height="339" alt="Снимок экрана 2026-07-21 143100" src="https://github.com/user-attachments/assets/fc015b93-514c-4d16-84e2-0909d5e6e3a1" />
<img width="211" height="335" alt="Снимок экрана 2026-07-21 143054" src="https://github.com/user-attachments/assets/04f9cd49-92bb-42f2-97ed-4e8b675d4367" />

After

<img width="226" height="238" alt="Screenshot 2026-07-31 163806" src="https://github.com/user-attachments/assets/7da6c20d-1124-44b2-a6b1-5f69ef69c6e1" />
<img width="250" height="266" alt="Screenshot 2026-07-31 163809" src="https://github.com/user-attachments/assets/56dcdc8f-2074-4845-aa97-d704016fdd77" />
@alisher372 alisher372 closed this Aug 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant