Codeberg/Community
54
325
Fork
You've already forked Community
12

Issue tab shows other people's repos #663

Closed
opened 2022年07月20日 13:44:55 +02:00 by fnetX · 5 comments
Owner
Copy link

I recall vaguely that we had this issue in the past, and fixed it, also with an early Codeberg patch (cc @ashimokawa).

If I open my personal Issue view at https://codeberg.org/issues, I see some repos I can't understand my relation with, e.g.

  • Freeyourgadget/Gadgetbridge
  • Fundevogel/kirby3-charts
  • shadow/SpyWareWatchdog

e.g. for Gadgetbridge: I'm not a member, nor watching it and I don't understand why I see a display of all the issues there. It's very confusing and looks broken IMHO.

I recall vaguely that we had this issue in the past, and fixed it, also with an early Codeberg patch (cc @ashimokawa). If I open my personal Issue view at https://codeberg.org/issues, I see some repos I can't understand my relation with, e.g. - Freeyourgadget/Gadgetbridge - Fundevogel/kirby3-charts - shadow/SpyWareWatchdog e.g. for Gadgetbridge: I'm not a member, nor watching it and I don't understand why I see a display of all the issues there. It's very confusing and looks broken IMHO.
Author
Owner
Copy link

Okay, another relation found: Fundevogel/kirby3-charts#2 (comment)

still very confusing IMHO, this should be changed.

Okay, another relation found: https://codeberg.org/Fundevogel/kirby3-charts/issues/2#issuecomment-465228 still very confusing IMHO, this should be changed.
Author
Owner
Copy link

(= only show issues I'm related to, not automatically show all issues of the repos where I'm related to one issue only)

(= only show issues I'm related to, not automatically show all issues of the repos where I'm related to one issue only)

All of the dashboard pages (pull requests, issues, milestones) build a list of repositories the user has access to, and display all PRs, issues, milestones within them, and allow filtering those (the code that collects these is in routers/web/user/home.go). It has no relation whatsoever to what one would expect: things the user has a relation to (other than access). If I open a PR against a repo I don't own, or have collaborator access to, it will not show up on the dashboard. This, I feel, renders these dashboards pretty much useless.

Rather than searching for repositories the user owns or has collaborator permissions for, these pages should list issues the user subscribed or contributed to. Though, if someone has posted a comment, but did not subscribe to the issue, I believe that should not be listed.

To put it more bluntly, this is how the list of things should be generated:

  • Any PR, issue, or milestone created by the user/org/team should be included.
  • Any PR, issue, or milestone assigned to the user/org/team should be included.
  • Any PR, issue, or milestone mentioning the user/org/team should be included.
  • Any PR, issue, or milestone the user/org/team is subscribed to should be included.

And that's it. This is pretty much how GitHub does it, as far as I can tell. GitLab is more limited: by default, /dashboard/issues will show issues assigned to the user only. Both GitHub and GitLab allow issue and PR searching, though, which lets one relax the conditions.

I think that as a first step, we should redo the list without a custom searchability option that GitHub and GitLab provide - that can be implemented separately, later.

I feel that a lot of the code from the user activity page could be reused for this purpose - I'll have a look.

All of the dashboard pages (pull requests, issues, milestones) build a list of repositories the user has access to, and display *all* PRs, issues, milestones within them, and allow filtering those (the code that collects these is in [`routers/web/user/home.go`](https://codeberg.org/forgejo/forgejo/src/commit/a94488cc989f48a5bc4418c1136e760a4871f9d1/routers/web/user/home.go)). It has no relation whatsoever to what one would expect: things the user has a relation to (other than access). If I open a PR against a repo I don't own, or have collaborator access to, it will not show up on the dashboard. This, I feel, renders these dashboards pretty much useless. Rather than searching for repositories the user owns or has collaborator permissions for, these pages should list issues the user subscribed or contributed to. Though, if someone has posted a comment, but did *not* subscribe to the issue, I believe that should not be listed. To put it more bluntly, this is how the list of things should be generated: - Any PR, issue, or milestone created by the user/org/team should be included. - Any PR, issue, or milestone assigned to the user/org/team should be included. - Any PR, issue, or milestone mentioning the user/org/team should be included. - Any PR, issue, or milestone the user/org/team is subscribed to should be included. And that's it. This is pretty much how GitHub does it, as far as I can tell. GitLab is more limited: by default, `/dashboard/issues` will show issues assigned to the user only. Both GitHub and GitLab allow issue and PR searching, though, which lets one relax the conditions. I think that as a first step, we should redo the list without a custom searchability option that GitHub and GitLab provide - that can be implemented separately, later. I *feel* that a lot of the code from the user activity page could be reused for this purpose - I'll have a look.
Author
Owner
Copy link

Oh, I think that the code must have changed between 1.20 and 1.21. Some repos that annoyed me a lot are now gone. (In the past, I always wondered what brought them up, since I had no access to them or something).

I suggest that we put this on hold and try to arrange a brainstorming about how we put these special pages to good use.

Oh, I think that the code must have changed between 1.20 and 1.21. Some repos that annoyed me a lot are now gone. (In the past, I always wondered what brought them up, since I had no access to them or something). I suggest that we put this on hold and try to arrange a brainstorming about how we put these special pages to good use.

To put it more bluntly, this is how the list of things should be generated:

I think I agree with @algernon's list.

I might have also liked the option to include everything from repositories that I 'Watch' - not only the PR/Issues/Milestones on them that I have interacted with or otherwise been associated with. But I'm not certain on this one.

> To put it more bluntly, this is how the list of things should be generated: I think I agree with @algernon's list. I might have also liked the option to include everything from repositories that I 'Watch' - not only the PR/Issues/Milestones on them that I have interacted with or otherwise been associated with. But I'm not certain on this one.
Gusted locked as Resolved and limited conversation to collaborators 2025年06月28日 00:17:11 +02:00
This discussion has been locked. Commenting is limited to contributors.
No Branch/Tag specified
main
No results found.
Labels
Clear labels
accessibility

Reduces accessibility and is thus a "bug" for certain user groups on Codeberg.
bug

Something is not working the way it should. Does not concern outages.
bug
infrastructure

Errors evidently caused by infrastructure malfunctions or outages
Codeberg

This issue involves Codeberg's downstream modifications and settings and/or Codeberg's structures.
contributions welcome

Please join the discussion and consider contributing a PR!
docs

No bug, but an improvement to the docs or UI description will help
duplicate

This issue or pull request already exists
enhancement

New feature
infrastructure

Involves changes to the server setups, use `bug/infrastructure` for infrastructure-related user errors.
legal

An issue directly involving legal compliance
licence / ToS

involving questions about the ToS, especially licencing compliance
please chill
we are volunteers

Please consider editing your posts and remember that there is a human on the other side. We get that you are frustrated, but it's harder for us to help you this way.
public relations

Things related to Codeberg's external communication
question

More information is needed
question
user support

This issue contains a clearly stated problem. However, it is not clear whether we have to fix anything on Codeberg's end, but we're helping them fix it and/or find the cause.
s/Forgejo

Related to Forgejo. Please also check Forgejo's issue tracker.
s/Forgejo/migration

Migration related issues in Forgejo
s/Pages

Issues related to the Codeberg Pages feature
s/Weblate

Issue is related to the Weblate instance at https://translate.codeberg.org
s/Woodpecker

Woodpecker CI related issue
security

involves improvements to the sites security
service

Add a new service to the Codeberg ecosystem (instead of implementing into Gitea)
upstream

An open issue or pull request to an upstream repository to fix this issue (partially or completely) exists (i.e. Gitea, Forgejo, etc.)
wontfix

Codeberg's current set of contributors are not planning to spend time on delegating this issue.
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Codeberg/Community#663
Reference in a new issue
Codeberg/Community
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?