Show Edit and WebIDE buttons more frequently by considering non-personal forks
Problem to solve
When a user clicks Edit or WebIDE buttons in order to edit a single file, Gitlab uses a personal fork if available, or offers to create a personal fork if the project settings allow forks. The use case not yet handled is when the user already has write access to a non-personal fork, but the project doesn't allow new forks. In this case, Gitlab wrongly hides the Edit button.
Intended users
The Drupal project is experimenting with a setup on Gitlab.com where lots of its projects are in a group called DrupalSpoons and those same projects are all forked into a group called DrupalForks. See this README section. The point is that everyone has Developer perms in DrupalForks and can collab there freely but the approved/golden code is managed by project maintainers in DrupalSpoons.
For example, when a Reporter clicks Edit or Web IDE buttons in https://gitlab.com/drupalspoons/devel, he should end up editing in https://gitlab.com/drupalforks/devel since thats its only fork and the user has Developer role in "drupalforks" group. Today, these buttons are not shown.
User experience goal
The goal is to let users edit files freely even though a project doesn't allow new forks.
Proposal
The MVP would be to only handle the case where user has write access to exactly one fork. In that case, use it. No new UI is needed for this. A deeper implementation is to ask the user which fork to use, in case user already has write access to more than one. The UI would be exactly like the UI when we ask the user which org to fork into.
Permissions and Security
No Security impact.
Documentation
If accepted, I'm happy to write a docs PR in case thats helpful.