Show depending and blocked PRs/Issues in the PR/Issue list (Resolves #29018) and added a divider between texts in the item-body

before:

after:

Two things I noticed while testing:

1. We should swap the order of blocks/depends on around, as the depends on is much more important in most cases, so should be the first info you see.
2. There's no clear separator when both are present, making the display slightly confusing. Not a blocker.

Apart from that, there might be some performance problems when querying a repo with many PRs/ a large dependency network. However, I don't know if they are (easily) fixable.
Otherwise LGTM.

I would lowercase the text. All other text on the line is lowercase, so it looks out of place to title-case.

Two things I noticed while testing:

1. We should swap the order of `blocks`/`depends on` around, as the `depends on` is much more important in most cases, so should be the first info you see.

2. There's no clear separator when both are present, making the display slightly confusing. Not a blocker.

Apart from that, there might be some performance problems when querying a repo with many PRs/ a large dependency network. However, I don't know if they are (easily) fixable. Otherwise LGTM.

I fixed it with a "|" between the list-items

This is my subjective opinion as someone who made the feature request, items in priority order (this PR might already do some of them in that case ignore those points):

• If the dependency is resolved (closed I guess) I don't want to see it in the depends_on list.
• The PR refs (#1) should be clickable
• I don't care if a PR blocks and for me it's not necessary to display it in the list, I only care if a PR is blocked since one way is enough to work out the dependency tree, and depends_on directly affects when that PR might get reviewed while blocks affects the other PRs instead.
• depends on is a bit soft wording because effectively that PR is blocked by other PR's and I would prefer that if said PR would indicate the blocked state more prominently. You could
  • Change the wording to blocked by (might be too similar to blocks)
  • Change the icon of the PR as well
• You might need to handle a big number of dependencies differently in the frontend, we sometimes have PRs with 5-10 dependencies. One option is that with 3+ dependencies you could just display #1, #2, #3 and more, but I'm not confident of a solution here.

With the exception of the first point if the things above sound unreasonable or they might not align with the majority of the people I'm ok with the current state of this PR.

This is my subjective opinion as someone who made the feature request, items in priority order (this PR might already do some of them in that case ignore those points):

* If the dependency is resolved (closed I guess) I don't want to see it in the `depends_on` list.

* The PR refs (`#1`) should be clickable

* I don't care if a PR `blocks` and for me it's not necessary to display it in the list, I only care if a PR is blocked.

* `depends on` is a bit soft wording because effectively that PR is blocked by other PR's and I would prefer that if said PR would indicate the blocked state more prominently. You could
  
  * Change the wording to `blocked by` (might be too similar to `blocks`)
  * Change the icon of the PR as well

* You might need to handle a big number of dependencies differently in the frontend, we sometimes have PRs with 5-10 dependencies. One option is that with 3+ dependencies you could just display `#1, #2, #3 and more`, but I'm not confident of a solution here.

With the exception of the first point if the things above sound unreasonable or they might not align with the majority of the people I'm ok with the current state of this PR.

1. Good idea, I will try to implement it
2. all links are clickable
3. You don't need this feature, but its now in the list and maybe someone needs it
4. 'depends on' is the official wording
5. Yes its correct, a large number ob dependencies is a bit ugly in the list, but how often is the number of dependencies so large? And when I do #1, #2, #3 and more its no longer possible to click the link directly. I will look into it, but currently I don't have a good solution.

UI looks good. Only thing that maybe could be improved is to manually emit the separators in HTML instead of CSS because I fear that the CSS selector may have false matches, but at least from the screenshots, it looks alright.

Ah, it works now after enabling that. I hadn't expected it to be locked behind a setting.

Its because of #29117 (comment)

I think the rendering could be made similar to milestone, with an icon before an no text besides issue numbers joined by ", ". The question is just which icons to use for "depends on" and "blocks". I don't think octicons has anything suitable, but https://www.svgrepo.com/ might.

I noticed the dot we added causes unsatisfactory rendering for link hover. We need to fix that, maybe just remove the dot after all. A bit of whitespace should be enough between items.

These two are pretty good already, We could switch the box to a rounded outlined square:

https://primer..io/octicons/package-dependencies-16
https://primer..io/octicons/package-dependents-16

There is also a fitting icon for a "issue blocks":

https://primer..io/octicons/issue-tracked-by-16

The idea is that if the arrow in the icon indicates the direction of the dependency, pointing from icon to the numbers for "depends on" and from the numbers to icon for "blocks".

@lunny I need the join repo for the link

func (issue *Issue) Link() string {

and this is important for

const {owner, repo, index} = parseIssueHref(refIssue.getAttribute('href'));

Or even more simplified icons:

https://primer..io/octicons/arrow-right-16 for "depends on"
https://primer..io/octicons/arrow-left-16 for "blocks"

Each with a tooltip over the icon. If you agree I can do the necessary changes directly on the branch.

These two are pretty good already, We could switch the box to a rounded outlined square:

https://primer..io/octicons/package-dependencies-16 https://primer..io/octicons/package-dependents-16

There is also a fitting icon for a "issue blocks":

https://primer..io/octicons/issue-tracked-by-16

The idea is that if the arrow in the icon indicates the direction of the dependency, pointing from icon to the numbers for "depends on" and from the numbers to icon for "blocks".

I think this Icons are better
And should this be a Icon per dep or just one Icon on the front?

One last thing, is it possible to change the color of the PR icon based on if the PR has unresolved dependencies? Creating a brand new icon for it is probably a stretch, even if Gitea currently does not use the PR closed icon for closed PRs.

To indicate more clearly that the PR cannot be merged so it's not worth reviewing (or it's dependencies are worth reviewing instead). If the dependency is a PR and is in the same repo it might be that the PR contains it's dependency, in that case a review is worth even less.

I'm not sure on the color (not green, red or gray because they are taken) and I don't know how hard it would be to do that. Also doesn't have anything similar.

And should this be a Icon per dep or just one Icon on the front?

One icon instead of the current text imho, to conserve space.

Meanwhile I've seen this icon in GitLab suite:

https://gitlab.com/gitlab-org/gitlab-svgs/-/blob/main/sprite_icons/issue-block.svg

So I would make two icons, similar to that one. Represent the issue/pr with a square and have arrows pointing in and out at bottom right, similar to package octicons above. If you can operate Inkscape or similar tools, please try creating these SVGs. Otherwise I will try 😆.

And should this be a Icon per dep or just one Icon on the front?

One icon instead of the current text imho, to conserve space.

Meanwhile I've seen this icon in GitLab suite:

https://gitlab.com/gitlab-org/gitlab-svgs/-/blob/main/sprite_icons/issue-block.svg

So I would make two icons, similar to that one. Represent the issue/pr with a square and have arrows pointing in and out at bottom right, similar to package octicons above. If you can operate Inkscape or similar tools, please try creating these SVGs. Otherwise I will try 😆.

Can someone do this for me? I'm not the best to edit/create SVGs

Sorry, haven't gotten around to making these SVGs yet, I will soon.

@zokkis SVGs added.

Want to integrate them? I'd say wrap them in a <div data-tooltip-content="Depends on"></div> and <div data-tooltip-content="Blocks"></div>.

[lunny]

Suggested change

	{{end}}
	{{end}}

[wxiaoguang]

Two nits:

1. Does it need a migration? For long time I have the question:
   • If a migration is a must, it should be documented in guideline and explained.
   • If a migration is not a must, then we do not need to require to write migrations
2. The index for IssueID seems redundant, because issue_dependency should already provide the index for it.

@zokkis SVGs added.

Want to integrate them? I'd say wrap them in a <div data-tooltip-content="Depends on"></div> and <div data-tooltip-content="Blocks"></div>.

In my opinion these are way too similar and hard to tell apart, but I prefer it to be merged, then someone else can raise it in case if it's just me.

Rethinking this PR, I believe two points need to be considered: first, whether it’s necessary to consume CPU resources to list these blocks; second, whether the UI will become too cluttered especially in the mobile UI.