Fix work item drawer Open in full page on issue boards (backport to 19.2)

Alexandru Croitorrequested to merge
19-2-stable-ee-backport-606339-drawer-expand into 19-2-stable-ee

What does this MR do and why?

Backport of two related fixes so that opening a work item in full page from the issue board drawer works on 19.2.

Original MR Commit on master Author
!246247 (merged) — Fix work item drawer expand crash on issue boards 7da38a2c35cf @gweaver
!246542 (merged) — Fix Open in full page action in board issue drawer 38cc13d56c61 Xingli Wu (JiHu)

Both were merged to master in %19.3. They fix the same underlying defect from two directions: the board IssueNode fragment provided only webPath, while work_item_detail_panel.vue read activeItem.webUrl. On issue boards webUrl was therefore undefined, so the click handler called e.preventDefault() and then visitUrl(undefined), which throws in startsWith. That silently turned the header reference link, the copy-URL button and the Open in full page button into no-ops.

  • !246247 (merged) requests webUrl in the fragment (matching the epic board fragment) and guards the disclosure_hierarchy.vue tooltip target.
  • !246542 (merged) additionally falls back to webPath when webUrl is absent, so the panel is robust regardless of which field the caller supplies.

Frontend and specs only — no migrations, no schema changes.

Why backport to 19.2?

The reporter confirmed the bug reproduces on self-managed 19.2.1-ee in #606339 (comment 3635450154). master has the fix as of %19.3, but 19.2 does not. Related to #606339 (closed) (severity3, bugfunctional).

Cherry-pick details

Both commits were cherry-picked with git cherry-pick -x, preserving original authorship. Verified content-identical to the master originals:

  • 38cc13d56c61 applied byte-identical.
  • 7da38a2c35cf differs only in hunk line offsets plus one deliberate conflict resolution, described below.

The one conflict

ee/spec/graphql/all_queries_spec.rb carries a GraphQL complexity override for lists_issues.query.graphql. Adding webUrl to the fragment raises the query's complexity, so the override had to move — but the 19.2 baseline differs from master's:

value
master before !246247 (merged) 580
master after !246247 (merged) 590
19-2-stable-ee baseline 560
this backport 570

Resolved to 570 (the 19.2 baseline plus the same +10 delta) rather than taking master's 590, keeping the override tight against the 19.2 query. The spec only asserts an upper bound, so 590 would also have gone green but with needless slack. Confirmed the relevant example actually executes and passes at 570 — it is not vacuously green:

$ bundle exec rspec ee/spec/graphql/all_queries_spec.rb -e "lists_issues" --dry-run --format doc
graphql queries
  complexity
    app/assets/javascripts/boards/graphql/lists_issues.query.graphql
      does not exceed complexity limit
  complexity override for app/.../lists_issues.query.graphql
    references an existing file
2 examples, 0 failures

Testing

Run locally against the 19-2-stable-ee base:

  • ee/spec/graphql/all_queries_spec.rb -e lists_issues — 2 examples, 0 failures
  • work_item_detail_panel_spec.js + disclosure_hierarchy_spec.js — 40 passed, 8 skipped
  • Full boards suites (spec/frontend/boards + ee/spec/frontend/boards) — 65 suites, 740 tests, all passing (these consume the changed mock_data.js)

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

  • This MR is backporting a bug fix, documentation update, or spec fix, previously merged in the default branch.
  • The MR that fixed the bug on the default branch has been deployed to GitLab.com (not applicable for documentation or spec changes).
  • The MR title is descriptive (e.g. "Backport of 'title of default branch MR'"). This is important, since the title will be copied to the patch blog post.
  • Required labels have been applied to this merge request
  • This MR has been approved by a maintainer (only one approval is required).
  • Ensure the e2e:test-on-omnibus-ee job has succeeded, or if it has failed, investigate the failures. If you determine the failures are unrelated, you may proceed. If you need assistance investigating, request help in the #s_developer_experience Slack channel to confirm the failures are unrelated to the merge request.

Note to the merge request author and maintainer

If you have questions about the patch release process, please:

Edited by Frédéric Caplette

Merge request reports