fix(jira): link tickets by their public address - #6757
Open
purisev wants to merge 2 commits into
Open
Conversation
ticket_url was always built from the host the provider connects to. When that host is internal - a cluster address, a proxy shim - every link Keep hands back is one nobody can open. Both providers already declare ticket_creation_url and never read it. Read it now: the public new-issue link gives the public base, and the connection host stays the fallback, so nothing changes for anyone who leaves the field empty. The link is parsed as a url rather than matched against one spelling of it, because Jira hands out the create form in several: CreateIssue.jspa, CreateIssue!default.jspa, either of them behind a context path and carrying a ?pid= query. A plain base url works too, with or without a scheme. A value that names no host at all keeps the links on the connection host instead of building a broken one. Signed-off-by: Iurii Purisev <92510590+purisev@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
See #6752.
ticket_creation_urlis declared in the authentication config of bothproviders and read by neither, and
ticket_urlalways comes from the host theprovider connects to. Where those differ, the link Keep returns opens for nobody
outside.
Fix
A
browse_hostproperty, identical in both providers, resolves the base for thelinks. It reads
ticket_creation_url, addshttpswhen the value carries noscheme, and drops a trailing
.jspapage along with the/secure/segmentholding it, so a create-form link in any of its shapes reduces to the site base.
Query and fragment go too, so
?pid=10000&issuetype=1does not travel into theticket link. A value naming no host falls back to the connection host, which at
least produces a link that opens, and so does an empty field. Both the create and
the update path in
_notifybuildticket_urlfrom the property.An installation that leaves the field empty sees no change.
Tests
tests/test_jira_provider.pygrows to 30 tests, all passing. A table of 13 URLshapes runs against both providers: create-form links with and without a context
path,
CreateIssue!default.jspa, a?pid=query, a bare host, a host with aport, trailing slashes, mixed case. Separate tests cover the fallbacks (empty,
whitespace, a value with no host, a bare path) and check that the
ticket_urlreturned by
_notifyuses the public host on both providers.Docs
Both provider pages get a "Public ticket links" section listing the shapes the
field accepts, the config field's description says it doubles as the public base
for returned links, and the autogenerated snippets are regenerated.
Note on the other Jira PRs
#6755, #6756 and the JQL one cover the other three reports on these providers.
This PR shares only
tests/test_jira_provider.pywith them, where the blocks areadded side by side.
Fixes #6752