Clickable links in pull request (and issue) titles #13695
Conversation
|
I don't really like this change for the issues/pulls list page because we currently use the title as the only link to the issue itself and having that end up being any number of links depending on the title seems annoying (I do dislike that this happens at certain spots for commits too, but in lots of cases anybody can create an issue title where as commits are at least restricted to code owners). It also opens up some minor abuse/ui issues as you can just make the title of issues something like "https://spam.com" and then the only place you can go from the list is to that outside site when clicking on the title (though I'm not sure titles really should/need to render Web links here). Similar if people happen to use really basic titles like "#100" etc... it could break the existing issues list. Since its not something you can turn off at all I'd rather it not mess with the current links on the issues list and avoid all issues above (as on Github). Changing it on the issue/pull page itself seems more OK as it doesn't have those same problems. |
|
You make some good points. What about only generating clickable links for issue references then, instead of also including all other different link types currently supported in the commit message rendering? The "really basic title" problem you highlighted is currently also problematic for commit messages. If you use "#100" as commit message, then on the commit page the link points to the issue instead of to the commit. |
|
If GitHub is any model, the only place where they do this link-in-link stuff is in commit titles (which we possibly already do?). |
|
I still think it is bad UI here to have the only way to get to specific issues/pulls be through clicking on the title in the list and then to let other links be in that same title (or even to be able to replace the link all together) depending on where you click. Commits at least have separate unmodified sha links and different interface/views. Github doesn't do this because they don't modify the title in any way (which is my personal preferences for titles, they are special and should not be altered ever). GItlab will render links and references in a issue title, but won't render those on the issue list page, just on the individual issue page (https://gitlab.com/mrsdizzie/wikitest/-/issues) for the same reasons listed here. The list page still only links to the specific issue regardless of what the title is, which is what I think would be best here as well if we're going to modify issue titles in any way. In general I see these postProcessors as a convenience -- they turn plain text that wasn't doing anything into something more helpful. In the case of the issues/pulls list its taking an existing link that is doing something and messing with it in a pretty opinionated way that isn't optional. I'd rather eliminate all of the issues mentioned then be able to use a section of the title for one issue in a list to get to a 2nd issue while breaking the model of "title = link to issue". It should be enough of a shortcut to have it in the title on the issue view for the case where it also isn't referenced in the content of the issue/pr. |
reuses the existing logic to render clickable links in commit messages
ee32f54 to
2550784
Compare
|
Ok, I have removed the link and reference rendering again for the issue / pull list views. |
This comment has been minimized.
This comment has been minimized.
applied patch from @mrsdizzie
|
pleace resolve conflict :) |
Codecov Report
@@ Coverage Diff @@
## master #13695 +/- ##
==========================================
+ Coverage 42.22% 42.26% +0.03%
==========================================
Files 699 699
Lines 76957 76974 +17
==========================================
+ Hits 32498 32530 +32
+ Misses 39098 39083 -15
Partials 5361 5361
Continue to review full report at Codecov.
|
|
@jpraet pleace "Update Branch" |
|
🚀 |
Fixes #13658
So this change change applies to both pull request and issue titles.
RenderCommitMessage(Link)logic. Ofcourse this means it is not clear from the method name now that those methods are also used for rendering Issue titles. Is that a problem? I could rename those methods to a more genericRenderTitle(Link)if that's preferred?