Allow hiding issue fork branches

I was expecting we’d want this feature, built some of the plumbing for it, but never got to creating an issue to make the UI. This will mostly need UI design, as branches are already hidden if their merge request is closed, which usually means un-merged.

I assume this is disabled on purpose to prevent data loss.

Now that we allow force pushes for issue forks, we could do the same and allow branch deletion. A tag of the deleted branch would be made, so nothing could be lost. This would fix that UX issue with GitLab not providing any feedback that the branch deletion failed.

I think I favor doing both - allowing branch deletion, and writing the syncing to Drupal.org, and hiding branches.

Is there a way to delete issue forks? I clicked "preview" on a different issue for some reason when you do the "preview" it also automatically selects "create issue fork"

Which “preview” link or button did you click?

There’s no harm in having an issue fork already open, it is fine to stay as-is.

At the bottom of each issue page there are three green buttons. "Save" , "Preview" and "View changes"

At the top of the issue page is the checkbox for "create issue fork"

You cannot see both at the same time.

To replicate this issue (1) unselect the "create issue fork" checkbox, then scroll all the way down and (2) press press that "preview" button.
then (3) press the save button.

Unbeknownst to you, after step (2) above, the "create issue fork" has become checked and is all the way at the top of the page so you don't see it. So a comment to an issue is now a fork.

So there's a useless fork. It's assigned to the person making the comment at git.drupalcode.org/dashboard/projects . Now I'm assigned a fork that should have been just a comment? Can't delete fork at www.drupal.org. Can't delete using git commandline, Can't delete at git.drupalcode.org .

Now because I have one useless fork assigned to me at git.drupalcode.org, when I click the "fork" icon to try to create a real fork (to work on a different issue and have a clean merge pull) git.drupalcode.org says "You've reached your (1) fork limit." I was actually looking to make a contribution on a different issue but weirdly now I have to put the contributions for a different issue in the only fork that's allowed for me? It makes no sense to me and seems bizarre.

For me, a messy and disorganized repo that can't be cleaned up by the author when errors occur, discourages contributions. Also for me having some weird forking logic that also prevents a user from having more than one fork also discourages contributions.

To replicate this issue (1) unselect the "create issue fork" checkbox, then scroll all the way down and (2) press press that "preview" button.
then (3) press the save button.

Unbeknownst to you, after step (2) above, the "create issue fork" has become checked and is all the way at the top of the page so you don't see it. So a comment to an issue is now a fork.

This should definitely be fixed, but I’m unable to replicate the issue. Which browser are you using and do you have Dreditor installed? To reduce the possibility of browser extensions interfering, does this happen in a private/incognito browser window?

The issue fork form and issue update forms are separate form tags. If we got them so one is contained in within the other, I could see that leading to this behavior; they are fully separate as far as I can see. This also explains the checkbox re-checking - since the issue fork form hasn’t been submitted on preview, it reverts to the defaults. The checkbox is specifically for whether a new branch should be created when the issue fork is created. The issue fork should only ever be created when the “Create issue fork” button is clicked.

(I clicked preview here myself, to double check the behavior.)

> Which browser are you using and do you have Dreditor installed?

Browser = Mozilla Firefox: 86.0+build3-0ubuntu0.20.04.1

Do not have Dreditor installed.

Extensions:
ublock origin (have tried both on and off: same issue)

and

noscript (allows fonts.gstatic.com, allows *.drupal.org, have tried both with newrelic.com on and off, have tried with googletagmanager.com on and off )

No other extensions.

Tested in Incognito mode. Checkbox still automatically activated when pressing "preview"

“with new branch from … named” checkbox being re-checked is expected. This won’t make a new branch or issue fork unless the “Create issue fork” button is clicked.

So far this issue does not have an issue fork, so neither of our updates has produced an issue fork after clicking “Preview.” I’m trying again, with Firefox this time, to see if I can reproduce this.

Is there anything I can do to help with this issue? Not experiencing the same issue as @rar, but would definitely like the ability to hide branches accidentally pushed upstream.

We currently have a "status" text field in the "drupalorg_issue_fork_branches" table. Currently, it's populated when a merge request is closed, and we can see hidden branches, as shown at the top of this issue.

I suggest using that property to show/hide the branch, but it'll be triggered from within the issue page, instead of reading from a merge_request webhook event.

The links to show / hide the branch could be something like this:

Clicking on these will write to the database directly, with no effect to any existing MRs status.

If we are happy with this approach I can work on it, otherwise happy to hear other options.

Let’s keep hiding/showing on MR on close/re-open with the webhook. Usually, closing the MR is a clear indication that it isn’t relevant anymore. (Core doing manual merges is an exception, but I think that’s okay.)

And, let’s add the UI to update the same drupalorg_issue_fork_branches.status field with the UI.

For UX, I could imagine people not knowing that hide/show will hide/show for everyone. With the old files UI, the Display checkbox and needing to save the issue is a bit heavier of an interaction, so you’re more likely to know it's updating the overall issue. We don't have a place to do that below “Add new comment” now, and I don’t think we should add one.

Adding links to the table as proposed should be best. Let’s keep the label simply hide/show, and add something like title="Hides branch for everyone"; we can do something different if we get reports that its confusing.

Ready to test:
- Styling issue for bluecheese #3400048: Style new link to show and hide branches within an issue
- URL to test: https://fjgarlin-drupal.dev.devdrupal.org/project/config_notify/issues/3...
- MR: https://git.drupalcode.org/project/drupalorg/-/merge_requests/207/diffs

Test cases:
- If users don't have fork access, the link will not be shown, and even if they were to find it and visit it, it will check their fork membership and bail out. They will need to request access and then the links will show.
- If users do have fork access, the links will show, and then you can show or hide the branch as needed.

This dev instance is not totally in sync with the gitlab dev instance, so it's kinda difficult to test the full journey without some html crafting.
Workarounds to test when you don't have fork access:
- If you try in this instance "Get push access", it will just fail. You can add the class "have-push-access" to the body of the page and the links will show.
- Then, when you click on the link, by default it will tell you that you do not have access (which is correct). To bypass this and test the actual toggling as if you would have access, you can edit the link "href" attribute and add "?bypass=1" (this bypass will be removed before deploying). The toggling should work in this case.

If we'd want to keep history of these changes, we could always generate a comment containing the operation and author, but for now I tried to keep it simple.

As per @drumm feedback. I am checking only if the logged in user has permissions to edit issues. Same test URL and MRs as 17.

Thanks for the feedback. Ready for review again.

All feedback was addressed.

Ready to test:
- Styling issue for bluecheese #3400048: Style new link to show and hide branches within an issue
- URL to test: https://fjgarlin-drupal.dev.devdrupal.org/project/config_notify/issues/3...
- MR: https://git.drupalcode.org/project/drupalorg/-/merge_requests/207/diffs

This has been deployed!

I think we should consider reverting this issue until and rework it so that it is clearer you are hiding the branch for all users. We've put the show/hide in the same location as the old show/hide button for files that used to collapse or open the files for the current user. This new button hides or shows for all users. You used to have to make a comment to hide files for all users. It's also near to the show commands button which also doesn't make a change to the issue for all users.

At the very least there should be a confirmation that you want to do this for all users.

Also I think that any change like this by a user should result in a comment. It'd be super annoying if a user went and hide MRs on 100s of issues and we did not know who it was.

I added the automatic comment when "hide" or "show" are clicked.
MR here: https://git.drupalcode.org/project/drupalorg/-/merge_requests/212/diffs
Test URL: https://fjgarlin-drupal.dev.devdrupal.org/project/config_notify/issues/3...

Styling will be like comments #10 or #12 in this same issue.

Clicking hide/show branch now posts a comment to the issue.

Fabulous, thanks! Confirmed this works at #3402293-15: Fix strict type errors: Convert FormattableMarkup to strings (simple replacement) in core/modules/*/tests/src/Kernel/*, too.

Here's an example of someone coming on to an issue an pressing the hide button when they didn't mean to https://www.drupal.org/project/drupal/issues/3405798#comment-15343738

I still think that this needs a confirm form as we've placed the hide / show buttons in exactly the same area of the issue as the show/hide files button and the show commands button. Both of these do make any permanent changes to the issue and only change things for the current user's current page.

A confirm form would be a good followup since we’ve seen people misunderstand this. Could be either https://developer.mozilla.org/en-US/docs/Web/API/Window/confirm or a Drupal confirm page.