<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=599179) </details> <!--IssueSummary end--> Work item detail modal broken when opened from the Related Issues list on an Incident page ### Summary When viewing an Incident (currently the only work item type that still uses the classic issue detail page), clicking a task-type item in the Related Issues list opens `WorkItemDetailModal` with multiple JS errors. The modal renders but most content fails to display correctly. ### Steps to reproduce 1. Navigate to an Incident work item's detail page. 2. In the Related Issues section, ensure at least one related item is of type Task. 3. Click the title of that Task. The modal opens. 4. Open the browser console -- multiple errors are present and the modal content is broken. ### Errors observed (browser console) - `[Vue warn]: Injection "hasSubepicsFeature" not found` - `[Vue warn]: Injection "hasLinkedItemsEpicsFeature" not found` - `TypeError: Cannot read properties of undefined (reading 'find')` in `work_item_actions.vue` (`showChangeType`) - `RangeError: Invalid time value` in `time_ago_tooltip.vue` - `TypeError: Cannot read properties of undefined (reading 'map')` in `work_item_award_emoji.vue` - `Error: Must provide fullPath && context` in `create_work_item_modal.vue` - `TypeError: Cannot read properties of undefined (reading 'split')` in `work_item_create_branch_merge_request_modal.vue` ### Root cause `related_issuable_item.vue` renders `WorkItemDetailModal` without passing the `work-item-full-path` prop: ```vue <!-- app/assets/javascripts/issuable/components/related_issuable_item.vue --> <work-item-detail-modal ref="modal" :work-item-id="workItemId" :work-item-iid="workItemIid" @close="updateQueryParam" @work-item-deleted="handleWorkItemDeleted" @openReportAbuse="openReportAbuseDrawer" /> ``` WorkItemDetailModal passes this prop (defaulting to '') straight through to WorkItemDetail. Several child components -- WorkItemActions, CreateWorkItemModal, WorkItemCreateBranchMergeRequestModal -- run their own Apollo queries or computed properties that depend on a non-empty fullPath. With an empty string they either get a null namespace back (making workItemTypes undefined and crashing .find() calls in showChangeType) or throw immediately ("Must provide fullPath && context"). The bug is present on master. It is only observable from Incident pages because Incident is currently the only work item type that still renders the classic issue detail page, which is where related_issuable_item.vue is used. ### Recommended fix work_item_detail.vue already loads workItem.namespace.fullPath as part of its GraphQL query. Rather than requiring all callers to pass workItemFullPath upfront, introduce a computed fallback: ```vue // in work_item_detail.vue computed resolvedFullPath() { return this.workItemFullPath || this.workItem?.namespace?.fullPath || ''; }, ``` Replace all internal uses of this.workItemFullPath with this.resolvedFullPath. This makes the component self-healing for callers that cannot know the full path before the work item loads, without requiring changes to every call site. A secondary fix (belt-and-suspenders) would be to pass work-item-full-path from related_issuable_item.vue once the correct value is known, but the fallback approach in work_item_detail.vue is more robust as a general fix for any future call sites. Affected files ``` app/assets/javascripts/issuable/components/related_issuable_item.vue app/assets/javascripts/work_items/components/work_item_detail.vue app/assets/javascripts/work_items/components/work_item_detail_modal.vue ``` --- The following discussion from !233018 should be addressed: - [ ] @clavimoniere started a [discussion](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/233018#note_3317096767): (+1 comment) > Found a fun edge case: > > 1. Open an incident (they're the only kind of work item that uses the old "issue" layout) > 2. Add a linked Task (has to be a task specifically) > 3. Click on that linked task > 4. This is, as far as I know, the only way to invoke the "work item detail modal" component. > 5. The work item detail modal will be broken. > > {width=900 height=359} > > I'm looking into what fixes this now.