Move `issue_type` to separate table to support user creation of types
Based on Customizable Issue Types, we need to support customers being able to create their own types.
Currently our issues
table contains an enum field (int2), issue_type
, which supports 3 values at the moment:
enum issue_type: {
issue: 0,
incident: 1,
test_case: 2 ## EE-only
}
In order for a user to be able to create their own types, with associated metadata and future customizations, we need to place these types in their own table, something like issue_types
, or issue_custom_types
issues_type |
---|
id |
title |
icon_id |
description |
description_html |
cached_markdown_version |
group_id |
Assumptions and questions
Scope
Based on the current description in Customizable Issue Types
Within a group (the top most parent group), CRUD types within an "issue types" list.
So the intent is to limit this to the top level group/namespace, and would dictate all the issues types for any issues below that.
The group_id
column is what ties those together.
Defaults
Based on the current description in Customizable Issue Types
Defaults:
- Feature
- Bug
- Issue
- Enhancement
- Tech Debt
- Incident
We can provide default issue types out of the box for the parent(any?) group.
- are these intended to be immediately available, or only if the customer opts-in?
- might make sense to have these be opt-in - a button would trigger their creation for a group.
- we should probably keep the base level
issue
type as a way for the customer to only use that if they want, or not use the defaults at all, but their own custom ones.