-
-
Notifications
You must be signed in to change notification settings - Fork 5.8k
add filter by author/assignee in /issues #25979 #26661
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
@CaiCandong this is the intended behavior |
84a82f5
to
9b59133
Compare
9b59133
to
15c444d
Compare
15c444d
to
c599320
Compare
aca34c5
to
6aad6ff
Compare
6aad6ff
to
1380c4b
Compare
1380c4b
to
cb6a227
Compare
@6543 can you take a look at this as well |
Whats the status here? if we update branch for conflicts - will you merge? its a very simple improvement :( This would help us use gitea for proper planning.. simply select a milestone (btw. we have added global milestones (will push PR very soon) - helps us group issues across repos based on features we work on) - and then we can just drag'n'drop to a week - and use our team labels - to easily see the plan for coming 4 weeks per team - and to fill those 4 weeks from our milestones. We were discussing putting 'planning' in a diff. page than issues - but its actually very few addons needed for it to work properly - so seemed very much like duplication.. |
Thank you for your patience, sorry there are too many issues/PRs that need to be handled. I think we can pick up this again. |
having a milestone assigned do at least shine a light when a featurefreeze happens ... so I'll assign it now |
about add filters etc ... to the global issue/pull dashboard, if not done right it gets more and more overloaded. the a related current discussion happend at #29701 (comment) for example ... |
@6543 You are absolutely correct.. also the issue pages for repo vs. global are different - thats also very odd (and causes confusion). We have a couple of dedicated UX'es who, work on these problems every day - overload vs. functionality etc. - I'd gladly ask to give an opinion if you want. I hope we do not disagree about the clear need for the ability to filter as such. Jira f.ex. has this - and its still a very popular product - so clearly that should not be in discussion :) |
@@ -764,19 +784,6 @@ func UsernameSubRoute(ctx *context.Context) { | |||
func getUserIssueStats(ctx *context.Context, ctxUser *user_model.User, filterMode int, opts *issue_indexer.SearchOptions) (*issues_model.IssueStats, error) { | |||
doerID := ctx.Doer.ID | |||
|
|||
opts = opts.Copy(func(o *issue_indexer.SearchOptions) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why remove these code?
@@ -33,6 +33,7 @@ const ( | |||
FilterModeMention | |||
FilterModeReviewRequested | |||
FilterModeReviewed | |||
FilterModeSearch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it should be a filter mode since this filter can combind with other filters. It's just standalone filters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we need some way to tell getUserIssueStats
func that poster/assignee filter is applied, otherwise it will put doerID in everything and the count(open/closed/total) will be incorrect
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
even if we pass opts with correct data, it wont apply without the filtermode
https://github.com/go-gitea/gitea/blob/main/routers/web/user/home.go#L792-L806
After playing with the issue list for a while, I think I could fully understand the problem now. I have posted my initial work here: Refactor issue list #32755 In short: it is impossible to add the filter by this approach. The root problem is that |
I will add the initial support after Refactor issue filter (labels, poster, assignee) #32771 |
Let's do this: Add label/author/assignee filters to the user/org home issue list #32779 |
…2779) Replace #26661, fix #25979 Not perfect, but usable and much better than before. Since it is quite complex, I am not quite sure whether there would be any regression, if any, I will fix in first time. I have tested the related pages many times: issue list, milestone issue list, project view, user issue list, org issue list.
Resolves #25979
PR sponsored by Obmondo.com