Add system defined widget definitions
What does this MR do and why?
After Add WorkItems::SystemDefined::Type class with data (!213380 - merged) is merged, we can add the widget definition system defined classes and data too.
This code refactors how work item types and their widgets are managed in the system. Previously, widget configurations were scattered and hardcoded in different places. Now, each work item type (like Issue, Task, Epic, etc.) has a clear list of which widgets (features like assignees, labels, time tracking) it supports, defined in dedicated configuration modules.
The changes introduce a new WidgetDefinition model that acts as a central registry for all available widgets and which work item types can use them. This makes it easier to determine what features are available for each work item type and handle conversions between different types.
The code also improves license checking - some advanced work item types like Epics and Objectives require paid licenses, and the system now better tracks which features are available based on licensing.
Key improvements include:
- Centralized widget configuration instead of scattered definitions
- Better support for determining which widgets are available during work item type conversions
- Cleaner separation between free and paid features
- More maintainable code structure for adding new widget types
This refactoring makes the codebase more organized and easier to extend when adding new work item types or widgets in the future.
References
Screenshots or screen recordings
| Before | After |
|---|---|
How to set up and validate locally
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.