#### Current work items state * **Incidents:** Work items but not fully widgetized (can't use work item detail view), so `useLegacyView: true`, locked from customization * **Tickets (Service Desk):** Will be fully functional work items eventually, but customization locked for now, creation disabled until required widgets are figured out * **Test Cases & Requirements:** Work items but don't use the work item detail/list views and shouldn't appear in the general work item list * **Tasks & Issues:** Fully functional work items with no restrictions * **Epics:** Work items but group-level only currently, locked for customization right now * **Objectives/Key Results:** Hidden behind feature flag, future unclear, customization restricted but are fully functional work items --- We'd like to get rid of hard-coded type checks in the backend and frontend apps. To do this we decided to use a configuration based approach where a type exposes a list of configuration/features/capabilities or settings. Both backend and frontend apps then only check the configuration and make behavior decisions based on that instead of checking whether an item is of type X. For the frontend app we would expose these settings/configuration on a new `workItemTypesConfiguration` query which only be exposing the configurations to keep it separate from `namespaceWorkItemTypes` query for performance and separation on concerns reasons For system-defined item we could just expose the settings as attributes on the system-defined type model, Custom types could use a similar approach (either delegated to the type it's based on or some dynamic evaluation).