feat(table): support embeddable question types inside table columns - #45
Closed
alisher372 wants to merge 5 commits into
Closed
feat(table): support embeddable question types inside table columns#45alisher372 wants to merge 5 commits into
alisher372 wants to merge 5 commits into
Conversation
## 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" />
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
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: