Draft an API structure for needed configuration
Proposal
Introduce a configuration based approach for removing the hardcoded checks in the codebase
The proposal is to introduce the widget level config under widgetdefinitions and broader configurations which are not associated with any type to the configuration key
Use cases
| Configuration name | Part of which API | Response example / Type | Any alternative to the current implementation | Related work item(s) |
@stefanosxan @engwan @msaleiko @cngo comments |
|---|---|---|---|---|---|
|
|
|
|
|||
|
|
|
|
|
What about if the namespace returns a type? Then you should be able to know which query to make? | |
|
|
|
|
|||
|
|
|
|
|||
|
|
|
|
|||
|
|
|
|
|||
|
|
|
|
|
||
|
|
` |
|
The condition for this to be passed in create work item modal is |
||
|
|
|
|
Only issues can be moved as of now | ||
|
|
|
|
Dates are rolled up only for epics |
type WorkItemType {
id: ID!
name: String!
iconName: String!
configuration: WorkItemTypeConfiguration!
}
type WorkItemTypeConfiguration {
supportsRoadmapView: Boolean!
supportsMoveAction: Boolean!
supportsTypeConversion: Boolean!
showProjectSelector: Boolean!
propagatesParentMilestone: Boolean!
useLegacyView: Boolean! // we can also use `isLegacyWorkItemType`
}
#import "./work_item_status.fragment.graphql"
fragment WorkItemTypeFragment on WorkItemType {
id
name
iconName
supportedConversionTypes {
id
name
}
widgetDefinitions {
type
... on WorkItemWidgetDefinitionStartAndDueDate {
rollUp
}
... on WorkItemWidgetDefinitionProgress {
showProgressPopover
}
... on WorkItemWidgetDefinitionHierarchy {
autoExpandTreeOnDrag
}
}
}
