Edit file workflow for creating a fork and proposing changes

[brechtvl]

When viewing a file that the user can't edit because they can't write to
the branch, the new, upload, patch, edit and delete functionality is no
longer disabled.

If no user fork of the repository exists, there is now a page to create one.
It will automatically create a fork with a single branch matching the one
being viewed, and a unique repository name will be automatically picked.

When a fork exists, but it's archived, a mirror or the user can't write
code to it, there will instead be a message explaining the situation.

If the usable fork exists, a message will appear at the top of the edit page
explaining that the changes will be applied to a branch in the fork. The
base repository branch will be pushed to a new branch to the fork, and
then the edits will be applied on top.

The suggestion to fork happens when accessing /_edit/, so that for
example online documentation can have an "edit this page" link to
the base repository that does the right thing.

Also includes changes to properly report errors when trying to commit
to a new branch that is protected, and when trying to commit to an
existing branch when choosing the new branch option.

Resolves #9017, #20882

---

[lunny]

1 A middle page may be necessary like GH did? Looks like GH will not display a fork form page and will fork at the backend.

2 The branches may be fixed as All branches to prevent to choose a wrong branch

3 Is that really necessary to allow user to fork to an organization when forking for the edit?

4 The edit button on README file of repository home page could be displayed.

5 Too many steps and it will make some beginner confusing.

[brechtvl]

I rewrote the whole thing, which should hopefully address all the comments.

I think the permissions checking is rather confusing now. Previously ctx.Repo.CanWriteToBranch, ctx.Repo.CanEnableEditor and ctx.Repo.MustBeEditable were easy to understand, but now that two repositories are involved it's no so simple anymore. Maybe I should add a ctx.Repo.UserFork into the context, so that these functions can use it? Suggestions welcome.

[lunny]

Fork repository was created after clicking the fork the repository button. But it redirects to 404 . And when I re edit the file,

[wxiaoguang]

The "fork" logic has too much legacy patched code, it seems that it is not good to introduce more patches, instead maybe it needs refactoring ....

And I think it needs tests to make sure the logic is overall right.

Do we have enough time to take it into 1.24? (TBH I guess no)

[brechtvl]

Fork repository was created after clicking the fork the repository button. But it redirects to 404 .

Fixed now, with test.

The "fork" logic has too much legacy patched code, it seems that it is not good to introduce more patches, instead maybe it needs refactoring ....

Ok, I'm not familiar enough with the overall code to see what is legacy here. Some hints or help would be appreciated.

Do we have enough time to take it into 1.24? (TBH I guess no)

I'm not in a rush to put it in 1.24.

[wxiaoguang]

Thank you for your work but sorry IMO we can't go with it like this.

I think it messed up the permission system. @lunny @hiifong please review again and suggest, or correct me if I was wrong.

[hiifong]

"i < 1000", it would be better if the number of branches could be used instead, although this condition is fine in most cases, but it can fail to work in some extreme cases.

[brechtvl]

Agree, though this is not new code. Is it worth changing as part of this PR?

[wxiaoguang]

Thank you for the update, but I think the design still breaks the Gitea's permission system, and would introduce more security problems in the future.

The problem is: all the existing logic bases on the fact that "middleware checks web ctx permissions" and "when permission check passes, the ctx contains the related targets (ctx.Repo)"

But this PR's design changes the ctx middleware behaviors, now every handler must process "GetEditableRepository" correctly and can't assume ctx.Repo is writable.

TBH I can't tell easily whether there would be more security problems, I would say no to this design, while I won't block it if you can guarantee the security is as solid as before.

[brechtvl]

Thank you for the update, but I think the design still breaks the Gitea's permission system, and would introduce more security problems in the future.

The problem is: all the existing logic bases on the fact that "middleware checks web ctx permissions" and "when permission check passes, the ctx contains the related targets (ctx.Repo)"

But this PR's design changes the ctx middleware behaviors, now every handler must process "GetEditableRepository" correctly and can't assume ctx.Repo is writable.

I agree this is a weakness, though I also don't have a good idea for how to do it differently. I considered switching the repos around and making ctx.Repo the editable one, but couldn't figure out a good way to do it.

TBH I can't tell easily whether there would be more security problems, I would say no to this design, while I won't block it if you can guarantee the security is as solid as before.

I've tripled checked everything by now. But I'm not sure how I could guarantee something like this. The logic is fundamentally more complicated and there are more chances for something to go wrong.