Adding private issues functionality

[Gusted]

Add the base functionality for private issues.

Resolves #3217

TODOs:

Optional TODOs:

• Allow to assign users to private issues, so they have access to it too (as long as they are assigned)

[delvh]

I know this PR is WIP, but I wanted to give you early feedback that you can integrate then early on.

[codecov-commenter]

Codecov Report

❗ No coverage uploaded for pull request base (main@a8fd765). Click here to learn what that means.
The diff coverage is 24.00%.

@@           Coverage Diff           @@
##             main   #17711   +/-   ##
=======================================
  Coverage        ?   45.50%           
=======================================
  Files           ?      807           
  Lines           ?    89960           
  Branches        ?        0           
=======================================
  Hits            ?    40932           
  Misses          ?    42480           
  Partials        ?     6548           

Impacted Files	Coverage Δ
models/error.go	38.42% <0.00%> (ø)
models/issue_comment.go	52.69% <ø> (ø)
models/org_team.go	56.21% <0.00%> (ø)
routers/api/v1/repo/issue.go	46.56% <0.00%> (ø)
routers/web/org/teams.go	0.00% <0.00%> (ø)
services/forms/org.go	0.00% <ø> (ø)
services/forms/repo_form.go	41.25% <ø> (ø)
services/issue/issue.go	24.74% <0.00%> (ø)
models/issue.go	56.83% <26.92%> (ø)
routers/web/repo/issue.go	38.87% <28.57%> (ø)
... and 4 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a8fd765...75c8a34. Read the comment docs.

[Gusted]

Please resolve conflicts

Done, sorry for the late action, school got me busy this month.

[qwerty287]

Needs a docs update in

gitea/docs/content/doc/features/comparison.en-us.md

Line 88 in c560ddb

| Confidential issues | [✘](https://github.com/go-gitea/gitea/issues/3217) | ✘ | ✘ | ✓ | ✓ | ✘ | ✘ |

[qwerty287]

Needs an update of string list below

gitea/models/issue_comment.go

Line 149 in c560ddb

"change_issue_ref",

[anonyco]

Any update? It's 2022 and there's $215 up for grabs at https://app.bountysource.com/issues/52815258-confidential-private-issues-on-public-repo

[mohe2015]

Any update? It's 2022 and there's $215 up for grabs at https://app.bountysource.com/issues/52815258-confidential-private-issues-on-public-repo

I think you should honor open source work a bit more. The last update was just 24 days ago which is not too much. I would estimate that this would be worth more than $215 if you would actually pay somebody to develop this. Also I don't think this should be rushed as this is security critical code. Approving is usually meaning you did a full code review and approve the code and I don't think you did.

[anonyco]

Thank you for politely calling me out on this and explaining the situation to me. You are right on all accounts.

I think you should honor open source work a bit more. The last update was just 24 days ago which is not too much.

I agree. I too often take for granted the countless man-hours that go into the development, maintenance, and upkeep of the 71,791 packages presently in my Linux Mint install.

I would estimate that this would be worth more than $215 if you would actually pay somebody to develop this.

A lot more.

Also I don't think this should be rushed as this is security critical code.

I agree. I had read through the entire discussion at #3217, so there's no excuse.

Approving is usually meaning you did a full code review and approve the code and I don't think you did.

Moreover on this, I do not know the Go language, which makes up the majority of the changes, so it's not possible for me to contribute any meaningful analysis of the code.

[6543]

please resolve conflicts :)

[Gusted]

I feel like the current path I'm taking is very hacky and not secure-by-design. We currently have Repository already under the context(ctx.Repo) and thus has one function that fetch the repo and do some standard checks. I think we might want to consider doing the same for Issues.

This way I can personally ensure the security of this PR is good and not your usual "Yeah, I think this seems fine", otherwise I feel like we're just opening ourselves to security leaks etc.

Any objections or better suggestions?

Adding status/wip is it's obviously not ready to be merged.

[Gusted]

I will close this PR, as this is too outdated and I strongly feel that this architecture(bunch of if checks are your security) isn't safe to be shipped. There needs to go more thoughts and decisions into a future PR for this issue in order to make sure it's safe for this to be used.