Requirements have customizable types. When you make a new requirement, its type is set to the default type but you can change the type at any time (if the workflow allows). This was the case before 6.13 and is still the case.
What has changed is what happens when you add a child to a requirement, making it a parent requirement. The table below summarizes how parent requirements work - changed with 6.13 are highlighted in bold in the right column.
| Parent Requirement | Old (pre v6.13) | New (after v6.13) |
|---|
| Has special icon | Yes | Yes |
|---|
| Real type is its original type | Yes | Yes |
|---|
| Visible type in the application | "Epic" (a pseudo type) | The actual type |
|---|
| Can you change the type? | No | Yes |
|---|
| Can you ever change the status (1) | No | No |
|---|
| Workflow controlling the details page (2) | Template default | Workflow in use for the actual type |
|---|
| Group by option on planning boards | "By Epic" | "By Parent" |
|---|
| Is Parent column on list pages | No | Yes |
|---|
| | | |
|---|
Notes:
(1): you can never change the parent requirement's status - it is always read only, because its status is determined by its children
(2): the workflow fully applies to what fields can be edited except that: you cannot perform any transitions, the Estimate Points field can never be edited