Web IDE button should fork and open forked project when selected from read-only project
Problem to solve
When a user browses to a project that they don't have write permission to they're unable to directly access the Web IDE from the main project page. This limits someone from quickly opening an editor to contribute to a project.
Intended users
All users who might contribute to a public project via the Web IDE via code or documentation or other kinds of contributions.
Proposal
The Web IDE button should be available in all public projects even if a user does not have Write access to that specific project. When a user who does not have write access to the project, the Web IDE button should create a fork of the project in the users namespace (regardless of other available namespaces) and then open the forked project in the Web IDE.
During the forking process we should provide information to user (similar to the standard fork process) that the project is being forked and that the Web IDE will open shortly.
Permissions and Security
This model should support all public projects where a user might have view access and be able to fork the project.
What does success look like, and how can we measure that?
Success should be an increase in the number of forked and then edited in the Web IDE projects. We could implement additional instrumentation on the Web IDE button, but with existing measurements we can measure number of forks and Web IDE usage to make broad correlations.
Proposal
After a first session with @himkp, we discovered that there are more different cases than initially expected where we have to change the behavior.
We decided to replicate the known behavior of the Edit button and the ACE single file editor in this issue to align the Web IDE with the known behavior of the Web IDE.
Case 1: I open the Web IDE from upstream project / default branch
User does not have a fork yet
- Modal to ask whether user wants to fork project
- Progress screen
- Web IDE with patch-1 branch
- Merge request leads to original project / default branch
User does have a fork
- Web IDE with patch-(x+1) branch + informing user that he is opening his fork (alert)
- Merge request leads to original project / default branch
Case 2: I open the Web IDE from upstream project / selected branch
User does not have a fork yet
- Modal to ask whether user wants to fork project
- Progress screen
- Web IDE with selected branch
- Merge request target to original project / selected branch (not current behavior yet)
User does have a fork
- Web IDE with patch-(x+1) branch + informing user that he is opening his fork (alert)
- Merge request leads to original project / default branch
Case 3: I open the Web IDE from forked project / default branch
- Already implemented
Case 4: I open the Web IDE from forked project / selected branch
- Already implemented
While working on this issue, it became clear that there needs to be a more obvious visualization whether a merge request from a new branch in a fork should have the default branch of the fork or the upstream project as target. This will be discussed in another issue.