When my custom hook reject a change made via Bitbucket's web editor, the UI forces me to create a new branch and a pull request: WHY?!

We are working on integrating the hook of our app (https://marketplace.atlassian.com/apps/1214430/better-commit-policy-for-bitbucket?hosting=datacenter&tab=overview) to Bitbucket’s web based editor. The UI/UX that is triggered by the file edit repository hook rejection event is totally confusing.

It seems that the control flow was designed to a single use case: when the change is rejected due to not having write permission on the branch. In that case, forcing me to create another branch is fine.
But, if the rejection is due to some other reason (e.g. I didn’t enter an issue key to the commit message), then forcing me to create another branch and a PR is totally misleading.

We have a custom com.atlassian.bitbucket.hook.repositoryPreRepositoryHook that responds to a com.atlassian.bitbucket.content.FileEditHookRequest (among other request types) to verifiy the commit messages.

Steps and problems when attempting to make commits using the web editor:

  • I make the change (01.png) and commit it (02.png).
  • Our app verifies the commit and decides to reject it as it violates the commit policy. So we construct the rejection message that explains the cause.
  • The custom rejection message is displayed correctly. So far so good.
  • But the dialog changes from a “commit” interaction to a “create PR” interaction:
    • The button’s caption changes from “Commit” to “Create pull request”.
    • The UI then offers to create a new branch for the PR.
  • Even worse, if but it might still get rejected if the commit message is wrong. Despite the commit being rejected, the provided branch will still be created!
  • From now on, every vetoed attempt will result in a “A branch with this name already exists. Try another.” message.

See the attached shots and this video: https://www.youtube.com/watch?v=O6cl926cClk

Expected behavior
If the commit is vetoed, the UI should not force the user create a PR (and a new branch).
In our case (which would also apply to other hooks, too), the dialog button should stay in a “commit interaction” until the reason why the hook rejected the change is resolved. No PR, no new branch.






Can anyone from the Atlassian team or vendors who integrated their hooks to the Bitbucket online editor confirm if it is a missing a feature or if I’m missing on something?