@msaleiko I'm not sure if this is exactly the same, but it would be nice that a "requirement" for anything related to work items is that it updates in real time. I'd be OK scoping this to the detail view for now, but ideally, it expands to anywhere a work item is viewed in both detail and aggregations (lists, boards, ..). For example, the linked items and child items widgets don't update in real-time for all connected clients, but the rest of the view does. This introduces conflicting behavior and drift that is cognitive overhead for users. WDYT?

We'll need UX (Nick and possibly Foundations) to weigh in on the desired path forward.

@rjackson-gitlab can you describe in more detail the use case for this customer? Thanks!

What does this MR do and why?

Adds viewContext tracking context to work item components to distinguish where a work item is being viewed. This helps us understand user interaction patterns across different surfaces. The context is included in the extra field of Snowplow tracking events across all work item widget components. Possible values:

• full_screen - work item is opened as a full page (default)
• drawer_list - work item is opened in the drawer from the list view
• drawer_board - work item is opened in the drawer from the board
• drawer_work_item - work item is opened in the drawer from another work item

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

@michold yes.

FYI @msaleiko

I'll get a release post item merged by the end of the week.

@vjain-gl yes, we decided not to prioritize this for the time being. Thanks for looping back! I do think we want to solve the "how do I get to my team's work with as few clicks as possible" problem, but there are enough unknowns right now that it doesn't make sense to solve it yet.

FYI @mmacfarlane @izzychu if I spoke incorrectly ;)

LGTM! Thanks!

@mckaile if you click the Change GitLab version link under the blue button, you should be able to define your own self-managed instance. Did you install the app manually or via the marketplace? Can you ensure all the prerequisites are met -- https://docs.gitlab.com/administration/settings/jira_cloud_app/?

@howellsm were you able to get this working? I agree there is a ton of room for improvement from an onboarding standpoint. Some is within our control, and a lot is not. Please let me know if you are still stuck. Thanks!

@vshushlin the problem with this is configurable work item types. Some customers will most definitely change the name issue to something else and not even have a work item type = issue. This is partly why we went the more generic route with the name. I hear (and understand) the feedback, but if something has been one way for 10 years and you change "that way," it's going to take some time to adjust to a "new way" 🤔

FYI @nickleonard

Priority should be setting a goal around meaningful activation. The best would be to target WAU taking action on work item from MR, either as a total or percent of possible WAU

☝️ Agree with this.