[Obsolete]
General
Keep progress of Workstream 3 for epics to work items migration.
Once we have the synching between Legacy Epic
and Work Item Epic
implemented in the code we would want to backfill data for all Legacy Epics
in the DB in order to later be able to switch from Legacy Epic
to Work Item Epic
Progress Legend
Progress tracking
Status | description |
---|---|
done | |
checked | |
not backfilled | |
next iteration | |
TBD |
Legacy Epic
and Work Item Epic
DB level data mapping between Click to expand
Legacy Epic | Work Item Epic | Notes and Comments | Progress Note | ||
---|---|---|---|---|---|
attribute |
table name |
attribute |
table name |
||
id | epics |
|
|
||
group_id | epics | namespace_id | issues | I-1: basic fields |
|
author_id | epics | author_id | issues | I-1: basic fields |
|
assignee_id | epics | assignee_id | issues |
|
|
iid | epics | iid | issues |
|
|
cached_markdown_version | epics | cached_markdown_version | issues |
|
|
updated_by_id | epics | updated_by_id | issues |
|
|
last_edited_by_id | epics | last_edited_by_id | issues |
|
|
lock_version | epics | lock_version | issues |
|
|
start_date | epics |
|
|
||
end_date | epics | ||||
last_edited_at | epics | last_edited_at | issues |
|
|
created_at | epics | created_at | issues |
|
|
updated_at | epics | updated_at | issues |
|
|
title | epics | title | issues |
|
|
title_html | epics | title_html | issues |
|
|
description | epics | description | issues |
|
|
description_html | epics | description_html | issues |
|
|
start_date_sourcing_milestone_id | epics |
|
|
||
due_date_sourcing_milestone_id | epics |
|
|
||
start_date_fixed | epics |
|
|
||
due_date_fixed | epics |
|
|
||
start_date_is_fixed | epics |
|
|
||
due_date_is_fixed | epics |
|
|
||
closed_by_id | epics | closed_by_id | issues |
|
|
closed_at | epics | closed_at | issues |
|
|
parent_id | epics |
|
|
||
relative_position | epics | relative_position | issues | The open question if we copy this over and if we do what would be the impact when Epic WI would be visible in WIs lists? The legacy Epic. relative positions would be totatly diff from WIs positions and that would most probably cluster Epic WIs either at the top or bottom of lists. | |
state_id | epics | state_id | issues |
|
|
start_date_sourcing_epic_id | epics |
|
|
||
due_date_sourcing_epic_id | epics |
|
|
||
confidential | epics | confidential | issues | ||
external_key | epics | external_key | issues | ||
color | epics |
|
|
||
total_opened_issue_weight | epics |
|
|
||
total_closed_issue_weight | epics |
|
|
||
total_opened_issue_count | epics |
|
|
||
total_closed_issue_count | epics |
|
|
Pre-backfilling requirements
-
Have the feature parity in place between Legacy Epic
andWork Item Epic
- TBD:
-
Color - Work Items - visualize records using colors (&10004 - closed) -
Start/Due date - Work items - Epic Start/Due Dates (&11409) -
Start/Due date rollup - Add WorkItem RolledupDates widget and graphql (#434834 - closed)
-
-
- TBD:
-
Have the code level synching in place between Legacy Epic
andWork Item Epic
- Workstream 2: Keep basic fields between epics a... (&12090 - closed) -
Add issue_id
column to epics table - Add issue_id to epics (!139788 - merged) -
Cleanup any non Epic work items
fromissues
table whereproject_id is null
- Create (namespace,iid) unique index on issues t... (!139827 - merged) -
Have a iid, namespace_id
unique index onissues
table - Create (namespace,iid) unique index on issues t... (!139827 - merged) -
Have the internal_ids
forepics
work withissues
usage type -
...
Edited by Alexandru Croitor