Fetch category information for lifecycle page from backend

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Should keep category information/config at one place (default color , name etc)

More reference , thread here

Also , I might be a little late for this , but IMO the category data should be coming from backend and not placed on the frontend(description is fine but for example color etc/). Like for example , we decide to add new categories , it should be simpler 🤔 Just a thought though 🙂

We could consider moving this to the backend in future iterations. Since categories are currently hardcoded on the backend, and we don’t have any API endpoints available (aside from querying a category name for a given status), we won’t be able to handle this on the backend before GA. Feel free to create a backend issue for it, though.

Add a new query GRaphQL status_categories in the ee namespace (like all other status related queries, lifecycles, statuses etc.) with a new CategoryType which is located similar to ee/app/graphql/types/work_items/status_type.rb.

Categories are located in ee/app/models/work_items/statuses/shared_constants.rb CATEGORIES. Icons are in CATEGORY_ICONS. Default state is in DEFAULT_STATUS_CATEGORIES. Work item state in CATEGORIES_STATE. Default colors, label and description need to be taken from the javascript objects below. Also add the enum identifier for the API from ee/app/graphql/types/work_items/status_category_enum.rb

The structure should be like this:

export const STATUS_CATEGORIES_MAP = {
  [STATUS_CATEGORIES.TRIAGE]: {
    icon: 'status-neutral',
    color: '#995715',
    label: s__('WorkItem|Triage'),
    defaultState: 'open',
    workItemState: CE.STATE_OPEN,
    description: s__(
      'WorkItem|Use for items that are still in a proposal or ideation phase, not yet accepted or planned for work.',
    ),
  },
  [STATUS_CATEGORIES.TO_DO]: {
    icon: 'status-waiting',
    color: '#737278',
    label: s__('WorkItem|To do'),
    defaultState: 'open',
    workItemState: CE.STATE_OPEN,
    description: s__('WorkItem|Use for planned work that is not actively being worked on.'),
  },
  [STATUS_CATEGORIES.IN_PROGRESS]: {
    icon: 'status-running',
    color: '#1f75cb',
    label: s__('WorkItem|In progress'),
    defaultState: 'open',
    workItemState: CE.STATE_OPEN,
    description: s__('WorkItem|Use for items that are actively being worked on.'),
  },
  [STATUS_CATEGORIES.DONE]: {
    icon: 'status-success',
    color: '#108548',
    label: s__('WorkItem|Done'),
    defaultState: 'closed',
    workItemState: CE.STATE_CLOSED,
    description: s__(
      'WorkItem|Use for items that have been completed. Applying a done status will close the item.',
    ),
  },
  [STATUS_CATEGORIES.CANCELED]: {
    icon: 'status-cancelled',
    color: '#dd2b0e',
    label: s__('WorkItem|Canceled'),
    defaultState: 'duplicate',
    workItemState: CE.STATE_CLOSED,
    description: s__(
      'WorkItem|Use for items that are no longer relevant and will not be completed. Applying a canceled status will close the item.',
    ),
  },
};

There're two options:

  1. Just add another constant that unifies all of this so we can expose categories (fastest approach)
  2. Introduce another system defined model using FixedItemsModel approach like ee/app/models/work_items/statuses/system_defined/status.rb with it's own methods etc. But this would require more refactoring because it'd make sense to then use the category objects throughout the application. But don't change the use for StatusCategoryEnum.
Edited by Marc Saleiko