Support multiple projects #27984

colonelpanic8 · 2023-11-10T06:59:52Z

Might still need some work

lunny · 2023-11-10T07:39:23Z

models/issues/issue_project.go

+	var ips []int64
+	if err := db.GetEngine(ctx).Table("project_issue").Select("project_id").
+		Where("issue_id=?", issue.ID).Find(&ips); err != nil {
+		return nil


err should not be ignored. I know the previous code should still be corrected.

delvh · 2023-11-10T11:28:50Z

I'm not sure if this functionality should be merged at all

It is an enormous maintenance overhead as the common assumption <= 1 project per issue needs to be completely discarded, and as such bugs will occur.
For example, assume someone deletes an issue. Someone might assume there is only a single project per issue and doesn't delete the rest.
The UI needs a complete rewrite
It makes it more complicated for the typical user:
As the UI is not tailored to support exactly one project anymore, errors are far easier making the overall user experience more painful
At the moment, I think it is a rare enough use case not to warrant all these changes.
Or tell me, how often do you think this feature is needed compared to how it increases the complexity (both from a maintainer perspective and a user perspective)?

yp05327 · 2023-11-13T04:20:22Z

templates/repo/issue/view_content/sidebar.tmpl

 			<a class="text muted flex-text-block">
-				<strong>{{ctx.Locale.Tr "repo.issues.new.projects"}}</strong>
+				<strong>{{ctx.locale.Tr "repo.issues.new.projects"}}</strong>


Why change ctx.Locale.Tr to ctx.locale.Tr?

not sure, this is likely something that was done by @tyroneyeh

ctx.Locale.Tr is from #27231 changed, ctx.locale.Tr is old version's

yp05327 · 2023-11-13T04:20:36Z

templates/repo/issue/view_content/sidebar.tmpl

-		<div class="ui select-project list">
-			<span class="no-select item {{if .Issue.Project}}gt-hidden{{end}}">{{ctx.Locale.Tr "repo.issues.new.no_projects"}}</span>
+		<div class="ui projects list">
+			<span class="no-select item {{if .Issue.Projects}}gt-hidden{{end}}">{{.locale.Tr "repo.issues.new.no_projects"}}</span>


Same as above

yp05327 · 2023-11-13T04:28:50Z

models/issues/issue_list.go

 		left -= limit
 		issueIDs = issueIDs[limit:]
+		for _, projectIssue := range projects {
+			issue := issueMap[projectIssue.IssueID]
+			issue.Projects = append(issue.Projects, projectIssue.Project)


Maybe we need to check whether projectIssue.Project is already in issue.Projects here.

colonelpanic8 · 2023-11-13T04:30:22Z

I'm not sure if this functionality should be merged at all

It is an enormous maintenance overhead as the common assumption <= 1 project per issue needs to be completely discarded, and as such bugs will occur.
For example, assume someone deletes an issue. Someone might assume there is only a single project per issue and doesn't delete the rest.

Maybe stop making these assumptions? But I mean where specifically, and why? Seems like a strange assumption to make to me.

The UI needs a complete rewrite

Why? Can you elaborate?

It makes it more complicated for the typical user:
As the UI is not tailored to support exactly one project anymore, errors are far easier making the overall user experience more painful

How is this not just you saying the same things you've already said?

At the moment, I think it is a rare enough use case not to warrant all these changes.
Or tell me, how often do you think this feature is needed compared to how it increases the complexity (both from a maintainer perspective and a user perspective)?

Multiple issues have been filed about this:

#12974

#25164

and also a previous PR:

#25164

conceptually restricting issues to a single project is very "worse is better" of you, but I guess I shouldn't expect anything different from the go community.

In any case, I'm not particularly interested in negotiating a bunch to get this merged.

I can probably just run from this on my own self hosted instance, but I thought that maybe others would be interested in keeping the original pr up to date, and maybe eventually someone who is motivated enough or a core contributor could use this as a base/foundation.

I kind of expect that people will not want to merge this, but at least its linked to the original pr and linked to the original issue in case people are interested.

Also, @delvh seems like this is listed as something @lunny (major contributor... who are you?) was at least somewhat interested in (see #14710). Your super dismissive attitude here is honestly kind of offputting.

yp05327 · 2023-11-13T04:32:45Z

models/issues/issue_project.go

-		} else if has {
-			issue.Project = &p
-		}
+			Where("project_issue.issue_id = ?", issue.ID).OrderBy("title").


Why we need to order the result here?
And maybe it is better to convert the function name into LoadProjects?

Again, this is just a holdover from @tyroneyeh 's original thing. All I did was try to resolve the conflicts.

I'm sorry. I was just reviewing this PR and didn't notice your comment above.
Are you planning to continually improve this PR or just resolve the conflicts?

This sorting applies to the sidebar menu list order

yp05327 · 2023-11-13T04:35:27Z

modules/indexer/issues/internal/model.go

@@ -26,7 +26,7 @@ type IndexerData struct {
 	LabelIDs           []int64            `json:"label_ids"`
 	NoLabel            bool               `json:"no_label"` // True if LabelIDs is empty
 	MilestoneID        int64              `json:"milestone_id"`
-	ProjectID          int64              `json:"project_id"`
+	ProjectIDs         []int64            `json:"project_id"`


Suggested change

ProjectIDs []int64 `json:"project_id"`

ProjectIDs []int64 `json:"project_ids"`

Other places also need to be modified.

yp05327 · 2023-11-13T04:42:03Z

modules/indexer/issues/util.go

+	var projectIDs []int64
+	for _, project := range issue.Projects {
+    projectIDs = append(projectIDs, project.ID)
 	}


Maybe a function is better? Just a suggestion. Then we can use it in other places if necessary.

delvh · 2023-11-13T11:10:29Z

@colonelpanic8

Maybe stop making these assumptions? But I mean where specifically, and why? Seems like a strange assumption to make to me.

I am not the one making these assumptions. Gitea is a project that is led by PRs from volunteers, many of whom have no in-depth knowledge of the code. These assumptions are coming automatically when you don't know the codebase well. That's what I mean by will be buggy.

The UI needs a complete rewrite

Why? Can you elaborate?

The current UI is set up to support exactly one project, both when assigning a project as well as displaying it (inside the issue, issue list, milestone, pull requests).
If you allow multiple projects, all these places need to be adapted to the new UI.
Additionally, many users rely on that the previous project is unassigned when you change the project, this wouldn't be the case anymore with multiple projects.

In any case, I'm not particularly interested in negotiating a bunch to get this merged.

Understandable

conceptually restricting issues to a single project is very "worse is better" of you, but I guess I shouldn't expect anything different from the go community.

I don't understand what the Go community has to do with this.
This is simply my personal opinion on what is best for the future of Gitea:
I am not categorically against this feature.
At the moment, there are too many loose ends whose behavior isn't clearly defined for me to allow this feature.
As such, it's my duty as a PR reviewer to clear them up before allowing this to be merged.
My "job" (I'm a volunteer after all) is making sure that Gitea doesn't end up bloated with features with inherent design flaws.
As I implied already, I have nothing against well-designed features.
As far as I know, all maintainers generally agree with this approach of only allowing well-designed features.

Your super dismissive attitude here is honestly kind of offputting.

Understandable.
But I think it is similarly understandable, that from my point of view, yours is equally bad. 😁

So, in conclusion, no, I'm not promoting worse is better, but only allow well-designed in the first place

tyroneyeh · 2023-11-14T01:04:52Z

We should seek official help to implement this feature. Instead of submitting wrong code and causing everyone trouble,

Thanks,

yp05327 · 2023-11-16T23:38:14Z

As we added organization/individual level project support in the early of this year,
I think it is necessary to support assign multiple projects, for users who want to manage issues not only in the repository level but also in the organization/individual level.

delvh · 2023-11-17T11:37:55Z

Hmm… Makes sense.
The question is: Is the usecase really support arbitrary many projects, or is it at most two projects with one repo and one user-level project?
Depending on that, the implementation will differ drastically.
Anyway, I don't think that's a discussion we should be having in this PR, better use the issue for it.

colonelpanic8 · 2023-11-17T18:44:34Z

implementation

Why would you limit things in that way. Furthermore, the database design already supports the one to many. Seems silly to insist on limiting things.

komali2 · 2024-02-14T08:48:08Z

IMO the UI seems to imply that issues might have multiple projects:

For our co-op, this is a critical feature that would let us do things such as show a "master board" of all issues across all our FOSS projects, something we really like on Github, and a big part of why we're migrating off github is the paywall behind having more than 5 FOSS projects feed automatically into another table. Even if we have to manually add issues per-project, it's still really nice.

So for us, that would be 1 repo level, and at least 1 organization-level project, but honestly possibly more if we can, for various organization reasons. I'm looking through the code now and I don't quite understand why arbitrary vs 1 org and 1 user is significantly different in complication, seems the future proof solution is better, but I defer to those more familiar with the codebase.

For what it's worth, I got 70 folks over here with time, unsure how many are interested in helping with this, but I and some others I were talking today are, so if "it's too complicated" is a major blocker, maybe we can throw our weight into the ring to help alleviate that concern?

komali2 · 2024-02-14T08:52:42Z

@delvh you seem to have the right sense of side-effects, that's good to have in a PR reviewer imo, I'm glad to see this project doesn't do "LGTM" and merges. It sounds like the main blocker for this PR right now is insufficient documentation of all the places that this change could effect (and actually handling those places in the code), is that right?

If so I'm happy to start documenting all the places at least in the UI that I suspect might be affected by this change. I'm still getting familiar with gitea (I'm just using in through codeberg right now, which isn't even really gitea lol) so I need to get a local deployment working and get familiar with the codebase, so any assistance connecting what I see in the UI with where that's reflected in code would be really helpful.

komali2 · 2024-02-15T06:22:26Z

Compiling UI locations I can see that will probably be affected by this change:

{org}/{repo}/issues/new?project={id}

The "Projects" list per new issue

Also, the "projects" list dropdown on the same page may be affected

Note for above, these issues might be created with a milestone preselected via query parameter:
/{org}/{repo}/issues/new?milestone={milestone_id}

/{org}/{repo}/issues/{id}

The notifications chain for an issue may be affected, as it indicates when an issue was added to a project

Also, that same page has likely the same component for the "projects" list and "projects" dropdown.

{org}/{repo}/projects/{id}

However, clicking "new issue" seems to redirect to the issue UI already mentioned above. I couldn't find any dropdown style or "live-add" functionality (such as github has) that would be affected by this change. Maybe I missed it?

Obviously, the kanban board view will be affected

{org}/{project}/issues

Potentially the "project" dropdown for a repo under issues tab might be affected?

The above URLs all can swap {org} for {user} and have the same ux, so, if those are handled differently in code, then those locations as well will be affected.

Surprisingly, I couldn't find any other locations in UX that might be affected. What other places am I missing?

komali2 · 2024-02-15T12:19:21Z

Also

{org}/{repo}/projects

Deleting a project is also probably effected.

tyroneyeh · 2024-03-29T00:38:17Z

Try new modifying #30163 again

yp05327 · 2024-04-08T02:59:54Z

Try new modifying #30163 again

So we can close this one?

tyroneyeh · 2024-04-11T14:11:28Z

Try new modifying #30163 again

So we can close this one?

Maybe?

@colonelpanic8

mkoskl · 2024-09-19T08:13:18Z

Another use-case for allowing multiple projects per issue. I'm tracking a data migration process from multiple (related) data sources via Gitea issue tracker.

Same textual data formatting rules apply to every data source / project. I have one issue for this textual data formatting and I would like to link it to all these projects.

wxiaoguang · 2024-11-17T09:01:21Z

Close according to #27984 (comment)

For #30381, I think it is almost there if it could follow the new sidebar design: #30381 (comment)

GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Nov 10, 2023

pull-request-size bot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Nov 10, 2023

github-actions bot added the modifies/frontend label Nov 10, 2023

lunny reviewed Nov 10, 2023

View reviewed changes

lunny added the type/enhancement An improvement of existing functionality label Nov 10, 2023

Support multiple projects

b9c8d5d

colonelpanic8 force-pushed the support-multiple-projects branch from df5261d to b9c8d5d Compare November 11, 2023 03:47

yp05327 reviewed Nov 13, 2023

View reviewed changes

yp05327 mentioned this pull request Mar 11, 2024

Multiple Projects Per Issue #29594

Open

tyroneyeh mentioned this pull request Mar 29, 2024

Add support multiple projects again #30163

Closed

silverwind removed the modifies/frontend label Mar 31, 2024

tyroneyeh mentioned this pull request Apr 10, 2024

Add support multiple projects again #30381

Open

wxiaoguang closed this Nov 17, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support multiple projects #27984

Support multiple projects #27984

colonelpanic8 commented Nov 10, 2023 •

edited by lunny

Loading

lunny Nov 10, 2023

delvh commented Nov 10, 2023

yp05327 Nov 13, 2023

colonelpanic8 Nov 13, 2023

tyroneyeh Nov 14, 2023

yp05327 Nov 13, 2023

yp05327 Nov 13, 2023 •

edited

Loading

colonelpanic8 commented Nov 13, 2023 •

edited

Loading

yp05327 Nov 13, 2023

colonelpanic8 Nov 13, 2023

yp05327 Nov 13, 2023

tyroneyeh Nov 14, 2023

yp05327 Nov 13, 2023

yp05327 Nov 13, 2023

delvh commented Nov 13, 2023

tyroneyeh commented Nov 14, 2023

yp05327 commented Nov 16, 2023 •

edited

Loading

delvh commented Nov 17, 2023 •

edited

Loading

colonelpanic8 commented Nov 17, 2023

komali2 commented Feb 14, 2024

komali2 commented Feb 14, 2024 •

edited

Loading

komali2 commented Feb 15, 2024

komali2 commented Feb 15, 2024

tyroneyeh commented Mar 29, 2024

yp05327 commented Apr 8, 2024

tyroneyeh commented Apr 11, 2024

mkoskl commented Sep 19, 2024

wxiaoguang commented Nov 17, 2024

	ProjectIDs []int64 `json:"project_id"`
	ProjectIDs []int64 `json:"project_ids"`

Support multiple projects #27984

Support multiple projects #27984

Conversation

colonelpanic8 commented Nov 10, 2023 • edited by lunny Loading

Choose a reason for hiding this comment

delvh commented Nov 10, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

yp05327 Nov 13, 2023 • edited Loading

Choose a reason for hiding this comment

colonelpanic8 commented Nov 13, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

delvh commented Nov 13, 2023

tyroneyeh commented Nov 14, 2023

yp05327 commented Nov 16, 2023 • edited Loading

delvh commented Nov 17, 2023 • edited Loading

colonelpanic8 commented Nov 17, 2023

komali2 commented Feb 14, 2024

komali2 commented Feb 14, 2024 • edited Loading

komali2 commented Feb 15, 2024

komali2 commented Feb 15, 2024

tyroneyeh commented Mar 29, 2024

yp05327 commented Apr 8, 2024

tyroneyeh commented Apr 11, 2024

mkoskl commented Sep 19, 2024

wxiaoguang commented Nov 17, 2024

colonelpanic8 commented Nov 10, 2023 •

edited by lunny

Loading

yp05327 Nov 13, 2023 •

edited

Loading

colonelpanic8 commented Nov 13, 2023 •

edited

Loading

yp05327 commented Nov 16, 2023 •

edited

Loading

delvh commented Nov 17, 2023 •

edited

Loading

komali2 commented Feb 14, 2024 •

edited

Loading